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ABSTRACT 


This thesis will evaluate system and process elements to 
initiate requirements modeling necessary for the next generation 
Digitized Aircraft Spotting (Ouija) Board for use on U.S. Navy 
aircraft carriers to track and plan aircraft movement. 

The research will examine and evaluate the feasibility and 
suitability of transforming the existing two-dimensional static 
board to an electronic, dynamic display that will enhance 
situational awareness by using sensors and system information 
from various sources to display a comprehensive operational 
picture of the current flight and hangar decks aboard aircraft 
carriers. 

The authors will evaluate the current processes and make 
recommendations on elements the new system would display. These 
elements include what information is displayed, which external 
systems feed information to the display, and how intelligent 
agents could be used to transform the static display to a 
powerful decision support tool. Optimally, the Aircraft Handler 
will use this system to effectively manage the Flight and Hangar 
decks to support the projection of air power from U.S. aircraft 
carriers. 
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EXECUTIVE SUMMARY 


The ability to make effective decisions with limited 
resources has never been more important. In view of recent 
asynchronous terrorist attacks on the United States, the ability 
to rapidly identify a mission, required personnel and critical 
material will make the difference between mission success and 
mission failure. 

Collaborative tools and environments with the addition of 
dynamic intelligent agents will be integral to successfully 
moving against adversaries anywhere in the world as they are 
revealed. 

Establishing a dynamic testing platform where emerging 
collaborative tools, intelligent agents, and "cutting edge" 
technology can be effectively and proactively integrated into 
all facets of flight deck planning and mission execution is 
logical and necessary. 

The primary benefit of a Flight Deck Collaborative Tools 
and Intelligent Agent Test Bed (or platform) is to provide 
accurate "requirements modeling" necessary for subsequent 
research efforts to effectively identify the collaborative tools 
and intelligent agents to support "Rapid Decisive Operations" in 
projecting air power. 

If the United States strategically plans to use military 
air power to overwhelm enemies, advanced dynamic collaborative 
tools and intelligent agents will be of paramount importance. 
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I. 


INTRODUCTION 


Oui • ja (w® j®, - j®) 

A trademark used for a board with the alphabet and 
other symbols on it, and a planchette that is thought, 
when touched with the fingers, to move in such a way 
as to spell out spiritualistic and telepathic messages 
on the board. 


A. BACKGROUND 

In the midst of the "War on Terrorism", the strategic value 
of U.S. aircraft cannot be underestimated. The ability to 
launch and land aircraft independent of an adversary's defenses 
and without the use of neighboring countries airfields gives the 
U.S. government great flexibility in projecting power abroad. 

The role of carriers in future conflicts will broaden to 
provide support for other U.S. military aircraft^, coalition 
aircraft, and possibly civilian humanitarian relief aircraft. 

The exponential increase in the use of Unmanned Aerial 
Vehicles (UAV) to include Vertical Take-Off and Landing Tactical 
UAV (VTUAV) and Tactical Control Systems (TCS), and future 
programs of the Naval UAV Long Range Plan, such as Naval Multi 
Role Endurance (MRE) UAV and Naval Unmanned Combat Aerial 
Vehicle (UCAV-N) will require robust command and control systems 
that can quickly adapt not only to changing missions, but also 
to the broadening range of aircraft to be safely launched and 
recovered at sea. 


^ Operation Enduring Freedom was unique in that the USS Kittyhawk deployed 
sans the Air Wing in order to use her as a Special Operations platform 
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While Army and Air Force fixed wing aircraft are not 
engineered for landing at sea, the recently awarded contract for 
Joint Strike Fighter (JSF), an affordable, multi-service 
aircraft that will replace several different aircraft in service 
today, could radically increase the number of fixed wing 
aircraft capable of leveraging the mobile aircraft carrier 
platform. 

Further, the time necessary to respond to a conflict will 
be critical. From the Office of Naval Research^; 

War fighters need the ability to strike time-critical 
tactical, operational, and strategic targets at the 
right moment in the battle. We therefore aim to help 
them project power and destroy, neutralize, or 
suppress targets of immediate importance to them. We 
are developing technologies that enable strike against 
targets in compressed vulnerability windows in all 
joint operations, in any environment, under all 
conditions. We don't want the enemy to be able to 
hide, or flee, or get in the first blow. 

Why is this Future Naval Capability important? Our 
future adversaries aren't likely to be so obliging as 
to present themselves as easily detected and 
classified stationary target arrays. They will be 
mobile or moving, they will do their best to hide in 
clutter, and they will be uncomfortably close to 
friends and neutrals. Our forces will need to deliver 
strikes with unprecedented accuracy, flexibility, and 
speed. 

In order to operate in "strike time", it is advantageous to 
have an integrated command and control systems that will not 
only display the present location of aircraft, but also 
facilitate dynamic mission planning and scenario driven 
solutions for mission execution. All phases of a mission could 


^ "A Future Naval Capability: Time Critical Strike", 

http://www.onr.navy.mil/onr/media/download/time_critical.pdf, June 7, 2002 


2 




be addressed including staging, maintaining, arming, launching, 
and recovering of aircraft. 

What is the status of the systems that currently support 
the planning and execution of aircraft handling on U.S. aircraft 
carriers? Preliminary research indicates that the display used 
for handling of aircraft on aircraft carriers is static and the 
process used for planning aircraft spotting is not automated. 

Aircraft movement is planned and tracked on paper, on fixed 
status boards and on the "Ouija" board (Figure 1) that provides 
a static reference for the orientation, location, and status of 
aircraft on the flight deck and aircraft in the hanger bays. 



Figure 1. The "Ouija Board" 


Two-dimensional templates of the specific aircraft are 
moved about this static table to represent each aircraft's 
relative position and orientation. Other symbology is used to 
represent processes or other maintenance information that change 
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or impact an aircraft's availability. For example, aircraft are 
prepared and moved for launch, recovery, re-arming, refueling 
and if necessary, maintenance. Figure 2 depicts representative 
symbology used on USS HARRY S. TRUMAN (CVN 75). 


1«Go 

Glean Pin J 

I 

2~*Go 

Yellow Pin 

J 



'I 


/yi spooler p(ns go on nose 
All spare pins go cn tae 


Alerts — U'hrit mulirrei runi6«,, 

7 - 7 minutes to get off the deck. 
15 -15 minutes ro get off the deck. 
30 “ ^ minutes to get off the deck. 
-$0 minutes to get off the deck 

Wing Spread -Wing Nut 

Low Power - Small Nut 
Turn (Silver) 

High Power - Large Nut 
Turn (Gold) 




Elevator - Black Pin ^ 
Down 


Wash - Washer 


T.O.D. - Orange Pin 


Fuel 

Defuel 

Low Flash Point 
Elevator Up 


- Purple Nut 
-Yellow Nut * 

- Red Nut ^ 
-White Pin 


Requesting 

Jacks 

On Jacks 


- Screw on 
it's side 

- Screw Up 



1 


Immobile - Clear Pin 


FCF - Blue Pin 


I 


Figure 2. "Nutology" Used Aboard USS Truman 


Movement and status of aircraft is collected via sound- 
powered phones, ships telephone circuits, radio, and messenger. 
On deck during flight operations, directions for the movement of 
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the aircraft could be relayed via radio, but is most often 
communicated via hand signals. Voice communication on deck 
between handlers and other deck crew is possible in the midst of 
turning aircraft engines, but a speaker would literally have to 
yell to each participant individually and depending on the level 
of environmental noise, the speaker might literally have to put 
his mouth within inches of the listener's hearing protection 
("Mickey Mouse" ears) to conduct his words effectively as 
illustrated in Figure 3. 





Figure 3. Verbal Communication on the Flight Deck 

The present system of handling aircraft using the static 
table works, but that can primarily be attributed to the 
diligent expertise of the professional handlers. While the 
present system works and is highly reliable, the information 
depicted on the Ouija Board is not readily available anywhere 
else. In fact, if any other decision makers or planners need 
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aircraft status, they would either call or physically visit 
Flight Deck Control where the Ouija board is maintained. 

While observing carrier qualifications on USS HARRY S. 
TRUMAN (CVN 75) from Flight Deck Control, it was obvious that it 
was the well-seasoned Aviation Boatswains Mates that made flight 
operations look well orchestrated, smooth, and safe. The 
reality is that physically moving aircraft on a carrier will 
always have a high level of risk. The manual system currently 
used to plan and track aircraft movement is very labor intensive 
with duplicate data collection and recording processes. This 
process is primed for a technology infusion. But considering the 
manual system "works", simply digitizing the existing processes 
will not be value added. It is our view that a digitized system 
should automate processes, reduce duplicate tasks, standardize 
inputs and share information to all assigned stakeholders. 

Therefore it is logical that emerging technologies now 
available, including wearable computers with miniature Heads-Up 
Displays (HUDs), Personal Digital Assistants (PDAs), and other 
wireless tools would be integrated into the next aircraft 
handling display and planning tool. 

This system becomes more than the Handler's display, but 
instead becomes the Situational Awareness display that will 
allow users to access all of the data stored in the vast array 
of systems currently in use. These large-scale relational 
databases are not being used to their greatest potential and 
require additional consideration in our project. 

We feel that the Air Departments' data and knowledge 
management would benefit greatly from the use of collaborative 
tools. Agent technology and dynamic Intelligent Agent Systems 
(IASs) . We discuss the use of agents in chapter VI. Software 
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agents are autonomous programs that are capable of gathering 
information regarding their environment and are then able to act 
in accordance to this information. They are in turn able to 
affect their environment by their actions. 

Our system's goals are not only a "real time" depiction of 
relative aircraft positions, but the use of software agents 
programmed that take into consideration all operational 
requirements that will impact planning, maintenance, fueling, 
de-fueling, arming, launching and recovering aircraft. 

Optimally, aircraft movement would be minimized. The 
Digital Ouija Board can suggest optimized move plans that 
minimize the movement or re-spotting of aircraft and the 
deliberate staging of aircraft for movement as required by the 
complex mission requirements for the current mission sortie and 
for subsequent sorties. The system would need to quickly assess 
all of the parameters that are routinely considered whenever re¬ 
spots are conducted. This is the ideal use of agents since they 
can be programmed to check the conditions of all the 
requirements and compare the outcomes of such qieries to other 
alternatives, and then provide a course of action that has been 
weighed against all of the possibilities. 

Intelligent agents could be used to prompt user interface 
while considering and tracking individual aircraft 
characteristics such as dimensions, turning radius, wingspan, 
jet exhaust and/or rotor wash envelopes and others as 
appropriate. Other items that agents could manage include 
maintenance, servicing assets for fueling, power, SINS (Ships 
Inertial Navigation System) cable, and support equipment 
(commonly called "yellow gear") location and availability. 
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The agents could be used, for instance, to validate track 
identification on the digital display. An agent is "assigned" 
to monitor the track and the track identification. Should the 
agent assess the correlation between the reported track and the 
identification of that track to be less than 80% sure (whatever 
value is determined to be the minimum threshold), then the agent 
will react by eliciting another agent that is responsible for 
determining who on the flight deck is closest to the track in 
question. Once this information is known, the agent can have a 
message sent to that individual to have them verify the aircraft 
identification to a designated operator in Flight Deck Control. 
This operator then inputs the data and the system is then 100% 
sure of the tracks identification. This same scenario may cause 
the agent to respond by instructing a flight deck camera to zoom 
in of the track in question. This would then provide the 
operator a video display that he or she can look at to determine 
the identification of the questionable track. 

Specific safety issues that could be addressed by 
intelligent agents include collision alerts between aircraft and 
between people and aircraft, object proximity alerts, and damage 
control and fire fighting (asset location/aircraft fuel 
loads/aircraft weapons load out). 

The system would be able to run in all phases of launch and 
recovery operations regardless of shipboard power or casualty^ 
situations. Therefore, other critical issues that we feel should 
be emphasized and addressed include system reliability, 
sustainability, and availability. 


^ A shipboard casualty would be damage incurred from an accident or 
inflicted by the enemy. 



Sustainability and redundancy could be accomplished ideally 
with synchronized laptop computers in primary workspaces, 
battery operated wearable computers and Uninterrupted Power 
Supply (UPS) outfitted servers below deck. An off site 
redundant server could also be established and synchronized via 
dedicated data link or data systematically spooled and pushed 
using available idle bandwidth. For example, the system could 
push cached or stored data over the data link, but would pause 
when another system required bandwidth for message traffic, 
email, video conferencing or other bandwidth intensive 
application. 

Up to date deck configuration and/or deck activity would be 
readily available on display repeaters at logical places 
throughout the ship (Bridge, CO's cabin. Command and Control 
(CIC), Ready Rooms, squadron maintenance control, etc.) and on 
deck and flight crew PDAs (either via wireless connection or 
infrared ports). 

When a mishap occurs, detailed video information could be 
extracted from archived "tracks" for aircraft, yellow gear and 
deck crew for both mishap and the events leading up to the 
mishap. 

A detailed summary of potential stakeholders that would use 
this system and the necessary intelligent agents that would 
apply and their functionality and, most importantly, their 
benefits will include but are not limited to: 

• CAG/Ship Information Agents: All of the data will be 
available throughout the aircraft carrier and 
conceivably could be shared across the CVBG or even to 
the theater commander. 

• Squadron Information Agents: Locate aircraft prior to 
manning or maintenance. Remotely "Click" on an 
aircraft icon to get "real time" status of weapons 
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load, fuel load, error codes, and maintenance 

information. 

System Network Monitoring Agents: Intelligent Agents 
could be used to passively monitor network node 
connectivity and availability. These nodes will 

include all the fixed sensors and all mobile PDAs and 
wearable computers on the flight deck. 

Deck Spotting ("Ouija" Board replacement) Agents. 
Flight deck and Hangar deck specific programs that 
optimize capture and record aircraft location and 
orientation. 

Knowledge Management. 

The system should record meaningful data and assign 
ownership of that data. Permissions should be 
established and assigned as to whether a user has 
read, read/write, delete, or change permissions (need 
to know). An audit trail detailing who initiated 
changes to elements of a plan or status of an aircraft 
should be maintained. For example, a mess specialist 
on the mess decks should not have the ability to 
change the readiness of an aircraft. The system 
should control access. If elements of a plan are 
needed, the system should prompt the "actor" with an 
automated email, phone call, page, or IMC 
announcement. The intelligent agents will dynamically 
collect data from all contributors and present 
scenario driven options for the Aircraft Handling 
Officer, for example, to select and promptly execute. 

• Operations can program in the flight schedule and 
the system of cooperative agents can determine 
the most efficient way to spot aircraft taking 
into account the real time status and location of 
the aircraft on the deck. This will also 
facilitate dynamic placement of aircraft during 
recovery and sequence aircraft movement to avoid 
delays or collisions. For example, the system 
could anticipate a collision and prompt one 
handler to pause until the threat passed. 


Intelligent agents could cooperate on providing passive 
integration with other systems so, for example, inbound aircraft 
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characteristics could be automatically assimilated into the 
system. The agent cooperative intelligence could continually 
evaluate information system data. Aircraft movement could be 
optimized though simulation scenarios. The intelligent agent 
could be running in the background or running in parallel would 
anticipate conflicts and then generate viable alternatives 
before conflict was realized. The system would prompt user 
interaction before problems materialize. 

The importance of the placement of aircraft prior to the 
day's first event is critical to how the carrier battle group is 
able to effectively execute the air plan. Since the air plan is 
made up of sequential sorties, all sorties should be considered 
before the first aircraft is move or re-spotted. 

Approximately seventy aircraft make up the current air wing 
on a carrier. The four and one-half acres of flight deck, plus 
the hangar deck, are used for launching and recovering aircraft, 
as well as storage and maintenance of aircraft. Deck space is 
also needed for loading and unloading, pre-positioning and 
short-term storage of ordinance. Additionally all of the Air 
Department's Flight Support Equipment (FSE) is operated, stored 
and repaired on the flight and hangar decks. The impact is that 
every square inch of the flight deck and hangar deck is actively 
used. We feel this use should be optimized and aggressively 
managed to ensure the fluid ballet of perpetually spotting and 
re-spotting of aircraft and equipment. 

One of the primary goals for the next generation aircraft 
carrier, CVNX, is that the platform generates 20% more sorties 
with the same type and number of aircraft from the same sized 
flight deck as today's Nimitz class carrier. It has not been 
specified how this will be accomplished, but it stands to reason 
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that increased flight deck efficiency could be realized by 
embracing technology and automating many redundant processes. 

The Handler and other key decision makers. Air Operations, 
for example, will need to have all the appropriate and accurate 
information at their fingertips in order to realize the 

efficiency goal. Decision support and process optimization 
software can aid the handler both in planning and in execution 
by decreasing the number of re-spots, thus increasing deck 
efficiency. A comprehensive system of this caliber does not 

currently exist, but all of the elements required for this 
system are available either in existing legacy systems or by 
using available technology. Of note, there is at least one 

vendor^ that we have been in contact that has developed a working 
prototype of such an integrated system, complete with a Digital 
Ouija Board. This prototype is not a complete working model, 
but it does prove the concept of how a totally revamped 

information system could be used to bring all of the data 

elements together 

The formal title for the Handler is the Aircraft Handling 
Officer (ACHO). The Handler is responsible for movement of 

aircraft on the Flight Deck and between the Flight and Hangar 
Decks in preparation for and during flight operations. Specific 
duties include the following:^ 

• Oversee Organizational Level aircraft maintenance and 
assure aircraft spots on the Flight and Hangar Decks can 
expedite the next two launches. 

Northrup-Grumman' s Newport News Shipbuilding Division has a prototype 
system, the CVN AirOps Management Information Systems Demonstrator 

^ NAVAIR 51-15ABH-1-74 Operation And Maintenance Aviation Data Management And 
Control System (ADMACS) And Integrated Shipboard Information System (ISIS), 
section 007, page 4 
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• Be aware of aircraft and report changes based on aircraft 
availability. 

• Track number of aircraft airborne, on the flight deck, 
and on the Hangar Deck, along with the weapon types on 
the Flight and Hangar Decks, and other flight deck 
equipment availability (i.e. AESS (Auxiliary Equipment 
Support Stations), Tilley, and fuel pumps). 

The current system uses a flat table-sized display board 
that has the scale outline of the flight deck as shown in Eigure 
4. The hangar is represented on a separate board that can be 
pulled out when needed. 



Eigure 4. Elight Deck Spotting (Ouija) Board Design 


The "Ouija Board", as it is known, has been used for at 
least fifty years. Scaled cutout models, or templates, of the 
aircraft are placed on the board to represent the relative 
position and orientation of the individual aircraft on the deck. 
Because the board is used both for planning and operational 
execution, the presentation may represent either the planned or 
actual aircraft position. If the representation is accurate, it 
is only depicting the reported position. This position is 
derived from by voice reports relayed to a "Blue Shirt" (usually 
a junior enlisted Aviation Boatswains Mate) phone talker who 
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receives aircraft position information from a lookout located at 
a vantage point in the island above the flight deck. Additional 
information is displayed on the two-dimensional models depicted 
previously in Figure 4 which will aid the Handler in making 
decisions. An example of such "nutology" is the use of a wing 
nut, which signifies an aircraft needing a wingspread. Usually 
a squadron representative or the CAG representative would let 
the Handler know of his desires to have a particular aircraft's 
wing's spread, typically for maintenance. 

In this sense, the Ouija Board is a rudimentary decision 
support tool. Due to its size it is not portable, so the 
information depicted upon it cannot be readily shared with other 
decision makers. A digital camera could be mounted above the 
static board and display an image of the table to other spaces, 
but the benefits of that display would be limited to what was on 
the table and would not be interactive. 

Depending on flight operations and the current location of 
the aircraft in relation to the flight line, spreading an 
aircraft's wings might hinder another aircraft launch or 
recovery. Instead, the aircraft might be re-spotted or delays 
spreading the wings until the higher priority operations were 
completed. 

The dominant impression of today's Ouija Board is that it 
works not because of technology, but because of the dedicated 
professionalism and experience of the fleet Handlers. This 
methodology is very labor intensive and doesn't allow the 
organization to share operational knowledge. Technology could be 
used to reduce redundant tasks and increase operational 
awareness throughout the organization, not just on the flight 
deck. 
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Equally important, there is very little in the way of 
written procedures or guidance on how to do the Handler's job 
and how to use the Ouija Board. Rules for the Carrier^ and the 
Air Department'^ personnel, as well as Personnel Qualification 
Standard's^ exist, but they do not describe how the Handler 
performs his craft, which has been described as something 
between "black magic and art" on more than one interview. 


There are some obvious shortcomings to the present system. 
The system is not automated in any way. The depiction of "real 
time" aircraft movement cannot be captured with any accuracy 
because of how changes are reported and then how changes are 
recorded. 


Figure 5 depicts the most 
traditionally named areas. 


common 


'landmarks' 


or 


SLASH PORT SHELF 


_ >1 • PlUVAIOIl 

•4 

C4 




>1 • ►lUVMOR * 



T * 


FArJTAIL 


i i 'h 

" - 5 




sMrir 






HU.0 

i H 

- j '1. ’ 




(LfVAIOP 

■j « 


L 4 PTAy ■ 

^ TAT - 


UPPCP 

STAOfJ 




^ ^ 


< Itaoii 


• I IMS r«>M 


LO« STAOiar. 
APEA 


STARBOARD SIDE 


Figure 5. Flight Deck Area Names 


in 

the 


For example, a Sailor could report an aircraft's pos 
gross terms of starboard, port, forward or aft in relati 
island, centerline, fantail (aft most area of the ship) 


it ion 
on to 
, bow 


6 NAVAIR 00-80T-105, CV NATOPS Manual 

7 NAVAIR 00-80T-120, CV Flight/Hangar Deck NATOPS Manual 

8 NAVEDTRA 43426-3 CV/CVN AIR DEPARTMENT OFFTCER WATCHSTATTONS 
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(forward most area of the ship), near one of the ship's 
prominent landmarks (i.e. elevator 1 or "LI"), or traditionally 
named areas including the "six pack", the "finger", or another 
known general area. 

The reporting sailor or "phone talker" positioned in the 
island overlooking the flight deck is not in a vantage point 
that allows him to observe the entire flight deck 
simultaneously. 

The phone talker in Flight Deck Control will listen to 
these reports, interpret them, and then simultaneously repeat 
the report out loud for the benefit of the Handler and either 
slide or pick up the template to move it to the new position on 
the Ouija board. Depending on the report, a log entry might also 
be made. 

What can make this reporting process more complicated and less 
reliable as a planning tool or operational decision support tool 
is that once a template is lifted from the board, true 
visibility of that aircraft on the board is lost. Arbitrary 
placement of the template after it is lifted doesn't give the 
Handler the historic placement or visual cues to determine what 
went wrong or anticipate conflicts based on projected movements 
of other aircraft in the same area. 

During interviews conducted for this thesis, we were told a 
"sea story" of how the Handler peered out his porthole (window) 
to see a completely different reality than the one depicted on 
the board. Being the sharp individual he was, he told the 
"phone talker" at the table to keep quiet for a moment. When the 
Handler ascended and arrived at the lookout point where the 
other phone talker was stationed, he found the other sailor 
sound asleep. It turned out that the first sailor was covering 
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for his sleeping buddy by periodically and randomly moving the 
aircraft templates on the Ouija Board to give the appearance of 
business as usual. 

The current Ouija Board does not serve as a truly "dynamic" 
display nor can it be considered dynamic as a decision support 
tool in regards to aircraft movement. 

B. PURPOSE 

While there are standard operating procedures for most 
redundant tasks in the military, in the area of aircraft 
handling, most processes and methodologies are learned on the 
job. 

The primary purpose of this thesis is to describe the 
requirements for a system that will display flight and hangar 
deck information, as well as assisting in the planning and the 
movement of aircraft on U.S. Aircraft Carriers. It turns out 
that the Digital Ouija Board is just a portion of a larger 
issue, that of information visibility. As such, we will include 
requirements that could be used for the carrier's air 
departments' information and knowledge management. 

Because of the complexity of handling aircraft in an 
operational environment, this thesis will serve as an 
introduction and general overview of the collective processes, 
ongoing systems improvement efforts, and will recommend the 
systems architecture solution and associated methodology that 
could be developed and implemented. 

Emerging and available technologies can be used to improve 
operational efficiency and effectiveness, but the organization 
must first understand how information is used in its business 
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processes and then how it applies to fulfilling mission 
requirements. 

The movement of aircraft is currently displayed on a static 
table. The value of the information held on this table is 
limited in terms of Command and Control because the templates 
used on the Ouija Board can only display where things currently 
are or where things should be. Information in this physical 
format cannot be easily communicated, manipulated, nor updated. 

Donald K. Krecker and David C. Knox from Martin Marietta 
Laboratories and John B. Gilmer, Jr. from Wilkes University 
stated. 

Command decisions are based on static knowledge, 
including doctrine, tactics and experience, plus 
dynamic knowledge of how the battlefield situation is 
evolving. The static knowledge informs a command 
post's intelligence, planning, and current operations 
functions, while the dynamic understanding of the 
situation is both an input and output of these 
activities. 

In order to increase the abilities of the personnel who 
routinely depend on the Ouija Board for situational awareness, 
it would be completely remiss not to include a dynamic display 
and an integrated knowledge base. This will allow users to 
drill down on a particular item of interest or to be alerted to 
an impending problem. Current carrier personnel agree that it 
would also incorporate elements that propose solutions to known 
problems and have the ability to "learn" as new issues arise. 

The advantage of adding a dynamic aspect to any display may 
seem intuitive. Studies have attempted to quantify the 
advantages and depict the knowledge gained by doing so. The 
illustration in Figure 6 depicts what the user gleans from a 
static display. 
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Figure 6. What is imparted with Static Display alone 


The addition of dynamic information in Figure 7 illustrates 
the value of adding the dynamic aspect to a display. The 
current system is by and large a static display. 
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Information on the current system is inaccurate in terms of 
exact position, latent in terms of displaying any type of 
aircraft movement, and incomplete in terms of real time display 
of actual aircraft position and orientation. 

We intend to make recommendations that will enable 
COMNAVAIRLANT and COMNAVAIRPAC to request NAVAIRSYSCOM to invest 
in developing an integrated solution for an updated Command and 
Control system. The "Fleet" requirements drive the development 
dollars. The cost benefit analysis of the current disjointed, 
inefficient system should make a strong case for a system that 
increases efficiency by allowing 100% data visibility and added 
decision support functionality. 

This system will enhance the War Fighters ability to 
perform their duties by leveraging the technology that will make 
them more informed so that they may make more informed 

decisions. The need to improve Command and Control is well 
documented and is one of the priorities that any new system 

would strive to accomplish. 

The need to model command decision support systems depends 
on increasing two items whenever possible; (1) Fidelity - to 
include cognitive as well as physical "battlefield" processes; 
and (2) Automation, in order to reduce the number of human 

decision makers in the loop^. 

In order for any system to accomplish an increase in value 

over the current, and very familiar, system, it must provide 

more than the status quo. To simply create a digital display 

that shows no more than the current system would be a wasted 

effort. Naval Air War Center, Lakehurst (NAWC Lakehurst) found 

® Donald K. Krecker: Martin Marietta Laboratories; John B. Gilmer, Jr.; Wilkes 
University; David C. Knox; Martin Marietta Laboratories; Modeling Situational 
Awareness for Command Decision Making 
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that the first digital version of any of the displays used 
aboard the Aircraft Carrier were nothing more than digital 
replacements. This has value in getting the users to accept the 
new version since it is visually the same. Feedback from users 
would only indicate the new system was a positive enhancement to 
the previous version when the new version expanded their 
capabilities. The Integrated Shipboard Information System (ISIS) 
is a prime example of this^^. True value is added when the 
replacement system provides additional functionality that 
increases the user's abilities or situational awareness. 

C. SCOPE 

The scope of this thesis is broken down into three primary 
sections. The first is to address the sensors that would be 
considered for use in capturing the raw data that the objects on 
the flight deck represent. There are many ways that such data 
may be brought into a computerized system; all of them have 
advantages and disadvantages in both the inherent properties of 
the sensor and in the way that they are employed. The carrier 
deck is a very extreme environment that is especially demanding 
on the equipment that is utilized in and around it. Many of the 
sensors considered could do a superb job if not for the fact 
that they will be subjected to jet aircraft exhaust, fuel 
spills, oil, hydraulic fluid, high winds, salt air, high 
humidity, etc. Additionally, the nature of the carrier and the 
equipment utilized there in requires the sensors to be low 
maintenance, accessible, and easily calibrated (either in place 
or aboard ship). All of these environmental factors will need 
to be mitigated in order for the sensor to be useful. 


From interviews of NAWC Lakehurst engineers 
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The second aspect is the display. We do not want to 
provide a solution that does not meet the needs or desires of 
the population we are attempting to assist. It is imperative 
that we conduct research into what it is the user wants this 
system to be able to do and what it will look like. Many of the 
"old salts" will resist the change outright. They may question 
the need to change a system that in their view "is not broken". 
In fact, it is conceivable that they would prefer to stick with 
what they know works. This familiarity with the existing system 
is natural and to be expected. Our coursework on managing 
change made this point abundantly clear. Again, sighting the 
ISIS work done by NAWC Lakehurst, it would behoove us to develop 
a system that is visually "similar" to existing systems. 

The third aspect is the integration and processing of the 
sensor information and the other systems currently in place. 
This will also incorporate the ability for the system to predict 
"best" actions for given scenarios. Accordingly, the system may 
require multiple agents to facilitate the interactions between 
sensors and systems whenever a data call is made so that the 
user will benefit from accurate and timely information. 

D. ORGANIZATION 

Understanding the aircraft carrier's operational 
organization from very general to very specific will impact the 
architecture of the system to manage aircraft handling on 
aircraft carriers. The organizational chart is an effective 
tool to help identify individual responsibilities and "need to 
know". More importantly, the charts initially help to delineate 
the "actors" or the individuals who either rely on the 
information summarized on the Ouija board to make decisions. 
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These are the individuals who have the power to add, change, or 
delete information that ultimately impacts effective mission 
planning and execution. 

At a minimum, identifying those actors with "need to know" 
will help determine how the information on the Ouija board would 
be distributed. Because of the sheer number of potential 
actors, dedicated Ouija board repeaters will be cost 

prohibitive, but web enabling the display is a viable option. 
For example, if the Commanding Officer (CO) of a squadron wants 
to find out the status and location of one of his aircraft, the 
CO could log onto the closest computer, open a web browser, and 
enter the Ouija board Universal Resource Locator (URL) address. 
He could then query the site for information on the specific 
aircraft and have that information readily displayed. 

The Ouija board is considered a key-supporting element in 
the command and control structure. The information represented 
on this element summarizes input from numerous sources and 
provide immediate feedback to all actors when changes are made. 

The organization of the Aircraft Carrier, the Air 
Department, the Air Wing, and the Aircraft Squadron are depicted 
in Figures 8 - 11. Each block on the chart represents either a 

single actor (a Commanding Officer) or a group of individual 
actors (the Air Department). If some actors appear in more than 
one chart, this may be a function of granularity. For example, 
the ship has a Commanding Officer, but each squadron also has 
its own Commanding Officer. 
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Figure 


Aircraft Carrier Organizational Chart 



Figure 9 


Air Department Organizational Chart 
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Figure 10. CV Air Wing Organizational Chart 



Figure 11. Aircraft Squadron Organizational Chart 


From these charts, general responsibilities can be 
determined. For example, the Commanding Officer of the carrier 
will be responsible to maneuver the ship and provide many of the 
services to support flight operations. These services will 
include electricity, fuel, and even steam for the catapults. The 
status of these services may not be depicted on the Ouija board 
itself, but the elements should be captured on the master 
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database and considered in the broad execution of flight 
operations. 

The Aviation Data Management and Control System or ADMACS 
is discussed and described in detail in Section III, Part D of 
this thesis. Appendix A provides specific actor input 
responsibility at the work center level for ADMACS. Many of 
these inputs will either be depicted on the Ouija board or will 
impact decision support elements being executed in support of 
the Ouija board. 
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II. SENSOR EXPLORATION 


In this chapter we will endeavor to describe several of the 
possible sensors that we considered as possible solutions to the 
data capture portion of our thesis. The list is representative, 
but not inclusive since there are certainly other sensors that 
we did not come across in our research. It does, however, 
provide a vast overview of the products that are available and 
to what degree they may apply to our problem. 

Discussions with the engineers that have been working on 
numerous related projects and by the guidelines explained to us 
in developing the requirements in this paper, we need to 
consider the following with regard to Sensor Selection. 

The sensors are required to involve no or minimal 
modification to aircraft for the following reasons: 1) 

Additional flyaway weight is frowned upon by the programs that 
are responsible for the aircraft. Keep in mind that weight is a 
critical factor in the performance and flight time duration. In 
the past, there has been much research into the type of paint to 
use in order to shave ounces off aircraft; 2) It may be 
bureaucratically difficult to require an across-the-board 
aircraft modification through nine different aircraft program 
offices; and 3) some identification tags are considered a 
Foreign Object Damage (FOD) hazard, something that could be 
ingested into a jet intake or fly up and hit someone on the 
deck. 

A general consideration that must be addressed besides not 

being able to modify the aircraft is minimizing the aircraft 

carrier's electronic emissions footprint. Laser ranging, 

although very precise in determining location and orientation of 
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aircraft, may have significant issues with scatter, stealth 
(especially with carriers operating in littoral regions), and 
eye safety. Major modifications to the ship would most likely 
be a showstopper. 

Deck Sensors embedded throughout flight and hangar decks 
could "sense" aircraft; however, with one sensor per square 
foot, this approach would require extensive deck modifications. 
There would possibly be over 100,000 sensors on the flight deck 
alone. Wiring all of these sensors would be a major undertaking, 
especially since the majority of the space directly beneath the 
flight deck would be extremely difficult to access. 

Conceivably, a vast network of these sensors working in a 
wireless environment could reduce the need for the data to be 
transmitted via cable, but then a reliable power source for the 
sensors and the transmitters would still be an issue. Even if 
this was a desirable thing to do, there are significant issues 
with mounting somewhat fragile sensors in an environment that is 
fraught with fuel and oil exposure, salt water intrusion, high 
winds and temperatures from jet exhaust, as well as the abuse of 
70,000 pound aircraft, dropped chains and turning tires directly 
on top of the sensor. Additionally, these sensors are only able 
to sense pressure. For example, the system could detect the 
pressure of a wheel, but it would be difficult to integrate this 
information with other sensors or discern aircraft orientation 
from only one input. Further, the system could not easily relay 
information about the other wheels. This would also be the case 
for aircraft identification, configuration, fuel status and 
weapons load. 

Differential GPS is accurate enough, but there are 
additional issues here beside the aforementioned "no 
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modifications to the aircraft" rule. GPS requires the sender to 
have a power source. The aircraft position information is 
needed when the aircraft is under its own power and when it is 
being towed or when it is parked. Hence, the use of GPS is also 
a non-starter. Again, if the aircraft modification and power 
needs were not an issue, there is the issue of requiring 
satellite information to determine the precise location of the 
aircraft on the flight deck. First, GPS requires simultaneous 
lock on a minimum of three satellites in distinctly separate 
sections of the sky. If only three where available, but two 
where close to the same line of site, or azimuth, then their 
information is no better than having only one satellite on that 
azimuth. Additionally, the GPS constellation consists of only 
twenty-four geo-synchronously orbiting satellites. 

Geosynchronous orbits do not provide 100% global coverage 
- the Poles would be left uncovered, hence the system would not 
work when the carrier is deployed above the Artie or below the 
Antarctic Circles. Furthermore, GPS requires line of site from 
the sensor to the satellite. Even with the Hangar Deck elevator 
doors open, the majority of the aircraft in the hangar bay would 
not be in line of site with 3 GPS satellites at all times. 
Hence, another system would be required for the Hangar Deck. 
And, just like the other sensors mentioned thus far, the use of 
GPS would not afford the system orientation information, 
identification or configuration information. 

We did consider the use of the aircraft's Identification 
Friend or Foe (IFF) signal for identification and location. This 
too is a non-starter for various reasons. First, it requires 
power and a user to input the correct codes that then identify 
the system to the ship's IFF receiver. Second, the aircraft IFF 
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is a power transmitter, and like aircraft radar, it is usually 
kept in a standby mode when on deck to avoid unnecessarily 
radiating the flight deck crew. It is likely that if all the 
aircraft where transmitting that the ship's IFF interrogator 
would not be able to distinguish who is who. Since the IFF 
interrogation response is sent back via radio wave, it is 
transmitted via an aircraft antenna. The disadvantage here is 
that with all of the Air Wing aircraft on deck in very close 
proximity to one another, the antennas of many will be blocked 
from clear transmission. 

Since the IFF was designed for use with the ship and 
aircraft radars, it is not optimized for use in pinpoint 
precision in a parking environment. Furthermore, the IFF 
position would be a point source, not a two-dimensional aircraft 
sized fix. As such, like the previously considered solutions, 
the IFF may be able to tell us where a particular aircraft is 
and which aircraft it is, but it won't be able to determine 
orientation and configuration. 

The Embarked Aircraft Tracking System's (EATS, described in 
Chapter III) engineers considered other "visual" data inputs 
such as an Infrared (IR) camera. The benefit here would be 
increased ability in low light or foggy settings. The 
disadvantage would be the cost (high end IR cameras are upward 
of $100,000). Other detractors are that these cameras are less 
able to provide the resolution required to obtain precise 
position and side number identification information. 
Additionally, the aircraft image may be less clear when either 
the aircraft has cooled to the ambient temperature or when the 
environment is hot enough to blur the lines of distinction, such 
as when operating in the Persian Gulf. 
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We did a partial survey of varying types of sensors to get 
a better appreciation of what industry has to offer. The below 
sections are the details as well as our opinion of the pro's and 
con's of each system. 

A. IR OPTICAL TRACKING SYSTEM 

The optical tracking system ARTtrackl & DTrack software 
from Advanced Realtime Tracking GmbH, a German corporation, has 
been used for Virtual Reality and Augmented Reality. The system 
consists of tracking cameras ARTtrackl, passive targets and the 
PC software DTrack. Some of the advantages to this system are^^: 

• Position and orientation measurement with high 

accuracy 

• Short latency, fast data communication via Ethernet 

• Passive targets that do not require battery or wiring 

• Tracking cameras with integrated IR flashes, complete 
software control makes them easy to use and easy to 
adapt to custom requirements 

• Flexible system setup with fast calibration, 

• Scalable system: no performance penalty for larger 
measurement volume covered with more cameras 

• Robust against electric and magnetic interferences 

• No optical cross talk between individual cameras 

This system was developed for tracking for virtual reality 
and augmented reality, virtual TV studios, body tracking for 
animation and ergonomics, industrial measurement applications, 
and image guided surgery. 

This system does not appear to be suitable to our 
application. One serious limitation to this system as it stands 
today is that it is limited to 10 targets. This may be less of 
http://www.ar-tracking.de/ 
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a factor as the software matures, so it is worth mentioning here 
for future consideration. Another limitation is that this system 
does require markers on the targets (Figure 12) , which is 
currently not permitted. 



Figure 12. Marker Required for "ARTtrackl" Sensor System 

Table 1 on the next page lists the technical specifications 
of the system. According to the company's data, the system 
seems to be extremely accurate with very little latency, 
attributes that are very desirable for our proposed system. 


data transfer 

Ethernet 100 MBit/sec 

frame rate 

max 60 Hz 

latency 

< 40 ms 

max number of targets 

10 

max. working distance 

4 - 10 m. depending on marker size 

system calibration 

within 5 min 

body calibration 

within 1 min 


Accuracy of a typical ARTtrackl & DTrack System (Example) 


Typical result for the tracking of a 
person s head position and orientation 
in a tracking area of 4m * 4m 
with a 4 camera tracking system 

target position 

target orientation 

accuracy absolute 
(RMS over whole measurement volume) 

250 pm 

0.12 deg 

repeatability 
(standard deviation) 

60 pm 

0 03 deg 

maximum error 

(calculated) 

900 pm 

0.4 deg 

noise 

(standard deviation) 

30 pm 

0.015 deg 


Table 1. ARTtrackl Technical Data 
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B. 


ELITEPLUS 


The Italian company Bioengineering Technology Systems has 
developed a system that can track minute movements of people^^. 
LITEplus is their new version of a fully automatic Motion 
Analyzer. The system features the ability to very quickly 
process and simultaneously collect analog and digital image 
signals. It is a real-time system; however, it is designed for 
and predominately used for biomedical purposes. It is not 
designed to track multiple targets, and therefore is not a true 
contender for use on the carrier, but there are some noteworthy 
characteristics that may apply to our application. 

The system is designed to run on a general purpose PC, so 
no special hardware for the computing needs is required. The 
system is able to recognize minute movements and is extremely 
accurate. 


C. OPTOTRAK 

The Canadian company Northern Digital Inc. manufactures 
OPTOTRAK^^. OPTOTRAK is a powerful, highly accurate 3D motion and 
position measurement system. It is reported to be both flexible 
and reliable, attributes that make it worthy of consideration. 
According to Northern Digital, "OPTOTRAK is considered the 
premier choice of industries, universities and research 
institutions around the world. Incorporating specialized sensor 
technology and sophisticated optics design, the OPTOTRAK 
delivers superior performance in 3D tracking and measurement." 

The system highlights some of the features that are 
considered positives in the industry. It is able to track 

http://www.bts.it/bts/products.htm, June 20, 2002 
http://www.ndigital.com/home.html, June 20, 2002 
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markers and rigid bodies, and it is able to identify markers 
automatically. When a track fall out it is reacquired and 
recognized immediately. Conversely, if the track reappears it 
is immediately associated and identified. These features may 
have direct application to the Digital Ouija Board since the 
likelihood of tracks dropping out of the system is inevitable. 

Accuracy is an issue regardless of the technology used to 
acquire the data. Northern Digital claims that their system is 
capable of precise data collection that in turn delivers 
exceptional results. Conversations with their systems engineers 
revealed, however, that the accuracy when applied to the vast 
expanse of the carrier deck would be less than optimal. While 
the system is capable of RMS accuracy to 0.1mm and resolution to 
0.01mm, the positional accuracy at the extremes of the flight 
deck could be as poor as 2 meters. It is our contention that 
this degree of accuracy, while better than the current eyeball 
method, is not accurate enough for the purposes of a truly 
automatic aircraft positioning system. The EATS prototype 
system is required to perform at no worse than eighteen-inch 
accuracy. This is the nearest we could find to a standard in 
terms of aircraft positioning accuracy on the flight deck. 

Other favorable features of the OPTOTRAK system are the low 
setup and calibration properties. The system is calibrated in 
the factory so it is ready for immediate use once it is 
installed. No other user calibration is required thus 
eliminating daily downtime. The system can be pre-configured to 
collect and store data instantly. 

Another potentially useful feature of this system is the 
"Multi-tracking" capabilities that allow simultaneously tracks 
of full body - hands and face with one simple system. Obviously 
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the design of such a feature did not have the application of 
tracking aircraft in mind, but this feature could be exploited 
for future applications that could conceivably monitor the 
catapult crews' motions to ensure that no steps are missed or 
performed in the incorrect order while hooking up an aircraft. 
Other possible uses could be as a flight deck event recorder. 
When a mishap on the flight deck occurs, the replay of the deck 
activity could reveal hand signals that may have been 
contributory to the mishap. Or conversely, the system may be 
used to exonerate a crewman who was implicated of making a 
grievous error when in fact the system shows that his or her 
hand signals or actions where correct. 

The system is capable of handling large, complex 
applications and can track up to 256 markers. The obvious issue 
here is that the system requires the aircraft to participate in 
the identification process, something that we have been 
prohibited from doing. Future versions may be able to use 
existing distinguishing organic characteristics of the aircraft, 
such as side numbers, as markers, and will be able to dispense 
with the current restriction that makes this and other systems 
unusable. 

A detractor from this system is the lighting requirements. 
Although the system adjusts to suit most indoor environments 
and is not affected by normal fluorescent lighting or metallic 
objects, it was not specifically designed for use in the bright 
sunlight or in the near infrared environment. These are 
considerations that would need to be addressed to make the 
system useable in all lighting conditions. 

There appears to be a few reasons why the OPTOTRAK System 
may not be the best solution for our project. OPTOTRAK is an 
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active marker based system requiring direct line of sight 
between the markers and the camera. The markers emit infrared 
light and therefore the system is designed for internal use only 
as sunlight will interfere with the marker tracking. The range 
in the depth dimension within which the OPTOTRAK can accurately 
determine 3 dimensional coordinates is 6 meters. The distance 
required is much greater than this to view aircraft on a flight 
deck. The Engineers at OPTOTRAK are quick to point out that the 
system has been engineered to obtain RMS accuracies to 0 . 1mm 
which is probably rtore accurate then the carrier based system 
requires. 

Overall, there are some definite attributes to this system 
that have applicability to the Digital Ouija Board and could be 
considered as a technological contributor when the system is 
fielded. 

D. BOUJOU 

Boujou is a camera tracker system developed by 2d3 Ltd, of 
Oxford, . The system's main function is to recover camera 
motion from pre-recorded film or video footage. As a 3D camera 
tracking system Boujou takes moving footage from film or video 
and by analyzing the footage automatically it calculates the 
position and characteristics (yaw, pitch and roll) of the camera 
that had shot it at each frame or field. In calculating the 
camera motion Boujou will also calculate the 3D structure of the 
scene in the video sequence. This in turn could be used to 
generate the precise location of a target from the camera. The 
system starts the tracking process by finding hundreds of 
features it can identify in each image; it then builds up tracks 

http://www.2d3.com, June 20, 2002 
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of these features over time. This feature could be useful in 
that the system would "learn" about the targets in its typical 
purview. 

There are a few drawbacks that would disqualify this system 
from serious consideration. Although it is a passive system, 
which is a plus, the system requires movement in 3D space in 
order to provide enough parallax information about the scene. If 
the camera is static then Boujou will not be able to work out 
how far away objects in the scene are (because there is no 
parallax) . 

This brings us to how we would employ this system. Here 
the camera is static but some parts of the scene are moving. 
This situation may still work with Boujou, since the needed 
parallax would come from distinct objects moving in an otherwise 
static scene. This has the added benefit of eliminating the 
redundant static scene since the system can be told to track the 
object and ignore the scene. This could be useful in that the 
tracking will only be needed for moving targets. Our system 
could simply create a last known fix for any target that stops 
moving, and the display will show that aircraft parked in its 
last known place and orientation. 

The biggest detractor to Boujou is that even though it can 
carry out its tracking without the need for manual intervention, 
the calculations are NOT real-time. This eliminates it as a 
viable alternative. Additionally, the current technology 
employed in this system uses visible red or infra red light 
emitted from a ring of strobe LEDs mounted around the lens. 
Natural daylight will swamp the light reflected from the 
tracking markers, which would render the system useless on the 
flight deck. 
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E. VICON 3-D OPTICAL MOVEMENT ANALYSIS SYSTEM 

Vicon Systems^^, the sister company to 2d3, is located in 
Lake Forest, CA. They have done extensive work in object optical 
motion capture and analysis; optical human, animal and object 
tracking; biomechanics, animation, sports, medicine and 
engineering. Relative to this thesis is their Real-time Object 
Tracking applications. The 3-D optical movement analysis systems 
from Vicon can be used to track humans, animals, golf clubs, and 
other sports equipment. It has been used for precision 
instruments for surgery and other medical applications, as well 
as Head Mounted Displays, robots, shapes, cars, machinery, and 
others. 

The Vicon system currently claims low latency, low noise 
and real-time data capability. They also claim to have a user- 
friendly communication protocol that allows users an easy 
interface to give them the ability to get trajectory, 
translation and rotational data into the system software. 

Vicon's motion capture systems are comprised of three main 
parts: specialized cameras, custom-designed high-performance 
computer hardware, and interlocking software programs. Up to 24 
high-definition Vicon cameras are arranged around the target 
area. These cameras are fitted with red or infrared strobe 
lights that illuminate small reflective markers fitted to the 
target whose motion data is to be captured. 

The cameras feed the motion of these markers to the 
computer hardware in real-time and the software interprets the 
data to reconstruct the 3D shape and actions of the moving 
object. The system is extremely accurate. 

http://www.vicon.com/, June 20, 2002 
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It may not be practical to place 24 cameras around the 
carrier deck, nor is it conceivable that we would use infrared 
markers to highlight aircraft and other objects on the flight 
deck. It is noteworthy, however, that this Vicon system is able 
to integrate image information from so many different sources. 

Since their system uses markers it cannot be used for our 
application, however the company is currently developing a 
system that will track without markers. It may be only a short 
while until they have perfected a system that may have 
application to the problem of tracking aircraft. Additionally, 
the engineer that we interviewed specifically mentioned that the 
new system would be able to track in ambient light. Their 
current system uses the Mega-Pixel Infrared Camera that allows 
users to obtain accurate 3-D positions of markers placed on all 
types of objects. Since they already have the ability to track 
using infrared, the low light level issue may be negligible, and 
with the addition of daylight capability, we feel that this new 
system is worth keeping in mind as the new the Digital Ouija 
Board is developed. 

This makes Vicon a possible vendor who may be able to 
easily modify their existing and future systems to the Navy's 
needs. 

F. AUTOMATIC VIDEO TRACKING SYSTEMS 

ISCAN Corporation of Burlington, MA manufactures the AVTS^®. 
There description of the system is as follows: 

ISCAN Automatic Video Tracking Systems (AVTs) are real 
time digital image processors that automatically track 
the movement of contrasting targets within the field 
of view (FOV) of an electro-optic image sensor, such 


^^http://www.iscaninc.com/ , June 20, 2002 
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as a video camera or a forward-looking infrared (FLIR) 
imager. 

ISCAN AVTs provide digital and analog outputs 
corresponding to the position and size of contrasting 
targets with respect to the electro-optic scan lines 
of the imager. The position and size of contrasting 
targets may be easily interfaced to computer systems 
for data acquisition or linked to azimuth/elevation 
tracking mounts for acquisition and accurate tracking 
of targets over a wide field of view. 

The ISCAN Model RK-447 Multiple Target Tracking System has 
the ability to track 256 simultaneous "targets" in real-time. 
ISCAN claims that their proprietary Simultaneous Multiple Area 
Recognition and Tracking (SMART) architecture is superior to 
other tracking systems that are easily confused by images 
containing more than one or rapidly changing target shape, which 
happens as the aspect changes in relation to the camera. The 
system is able to determine the targets' position and size data 
automatically. The system is capable of updated every 16 msec 
(62.5 frames per second) and the output is already designed for 
input to a computer. This refresh rate is significantly higher 
than that for motion pictures (30 frames per second) or the 
current EATS's 30 frames per second. The frame rate may not be 
a real issue since the aircraft we are tracking are not moving 
very fast. 

The ISCAN system is designed for simple operation and 
already has a fixed camera mode of operation, thus reducing the 
effort to make the system work in a reverse application where 
the system normally moves and is looking at stationary targets. 
This system will work either way. The ISCAN system can be used 
with many of the standard cameras commercially available today. 
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and can therefore take advantage of the camera's low light 
capabilities, much like the EATS described in chapter 3. 

ISCAN has designed the system to work on PC with standard 
software and hardware that is available off-the-shelf. This 
avoids the need for developing proprietary solutions that will 
eventually create maintenance and interface issues, as the 
system gets older. 
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III. CURRENT PROCESS ANALYSIS 


A. THE CURRENT SYSTEM 

The current use and description of the system was outlined 
in the introduction. There are numerous projects that are in 
development or proof of concept that are worthy of discussion 
and description. 

In preparation for this research, we developed an aircraft 
handler's questionnaire for the operator on the flight deck. 
This questionnaire is in Appendix B. Appendix C features the 
modest feedback we received from the fleet. The primary benefit 
of including these two appendices in our thesis is to provide a 
baseline for future initiatives. 

B. EMBARKED AIRCRAFT TRACKING SYSTEM 

This current prototype system is under development by NAWC 
Lakehurst and Develosoft Corporation in Boulder, CO^’^. The 
primary purpose of this system is to capture the aircraft 
position, orientation and trajectory then to display this 
information in a digitized form. 

The contract was awarded to demonstrate the feasibility of 
an Embarked Aircraft Tracking System (EATS). EATS requires 
sensor imagery of the flight and hangar decks to locate, 
identify, and track carrier embarked aircraft. EATS will be 
fully automated and hopes to significantly reduce errors due to 
100% field of view and sensitive imaging that can "see" in poor 
illumination and inclement weather. 


Navy Contract N68335-98-C-0137 
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Additional benefits that are available from the EATS are 
that any LAN connected air department space (e.g. Primary Flight 
Operations) has instantaneous access to embarked aircraft 
positions and status. Realize that the EATS sensor inputs 
provide far greater situational awareness of the decks than is 
currently possible with existing closed caption television 
(CCTV) or the Integrated Launch and Recovery Television System 
ILARTS^^ cameras. The system also provides more efficient data 
passing than the current communications system that relies on 
sound powered phones and hand delivery of information. EATS 
will have digitized video enhancement and will be able to 
provide capabilities that will allow digital illumination of 
dark areas. Specific users will have the capability to 
instantaneously zoom the view to areas of interest. The system 
will also have the capability to digitally record flight 
operations or deck activity so it can be replayed (in fast 
forward, reverse, single frame modes) and be used for training, 
planning, and optimizing sortie rates. 

As mentioned previously, EATS is a developmental 
application to prove the concept of 100% visualization of the 
flight deck and digital display of what the system "sees". From 


In order to constantly monitor flight operations, aircraft carriers employ 
a system of cameras and displays called the Integrated Launch and Recovery 
Television System. The ILARTS system allows the ready rooms, flight deck 
control, and the combat information center to view recoveries, launches, 
aircraft movements on the deck, and other activities, enabling a rapid 
response in case of emergencies as well as a tape archive that can be used to 
investigate a mishap. A key component of ILARTS is the manned island camera, 
which is located about 40 feet above the flight deck. The island camera is a 
pan, tilt, and zoom (10:1 zoom lens) that picks up the aircraft as it grabs 
one of the arresting wires, zooms in for a close up to pick up the aircraft's 
side number and follows the arresting wire back to its sheaves to determine 
which of the wires was engaged. If the aircraft bolters, the cameraman 
follows the aircraft as it departs the ship. The island camera also tracks 
each of the aircraft as it launches from the time it is in the catapult out 
to a half-mile. 
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our perspective it is a data input system that seems to be 
working well^^. 


The goal of establishing the feasibility of embarked 
aircraft tracking from carrier-mounted sensors has 
been achieved. Many hours of test imagery were 
acquired during day and night flight operations aboard 
the USN Carl Vinson (CVN 70). This imagery was 
successfully used to demonstrate accurate 
identification and location of aircraft with advanced 
image processing, pattern recognition, location, and 
tracking. These algorithms were tested under numerous 
difficult conditions: obscured aircraft; nighttime; 
severe optical distortion and optical aberrations 
(blooming); and camera motion. The test and 
demonstration environment consists of a split screen 
Windows application with recorded video images 
appearing with digitized stationary and moving 
aircraft (whose type and positions were computed 
through EATS algorithms). The accuracy and speed of 
EATS algorithms is easily demonstrated within this 
environment on numerous video sequences (day, night, 
flight and hangar decks). It is readily apparent that 
computed aircraft types, wing articulation, positions, 
and orientation are correct. 


The research and development of EATS has in effect proved 
the concept of a sensor driven system that can input data to a 
system, and then display that data as real-time tracks on a 
digital display. 

It is our opinion that this system is very capable of 
performing its stated function. Erom the limited amount of 
feedback we received from NAWC Lakehurst, the system does not 
provide the Handler with as much information as he has 
currently. If the EATS were fielded today, it would not be able 
to replace the Ouija Board as the Handler's primary decision 
support tool. EATS is a significant improvement in that the 

Based on E-mailed information from Develosoft 
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Handler, in our opinion, should have - a significantly better 
picture of where all the Air Wing aircraft are at any given 
time . 

It has been reported that the EATS system does not have the 
capability, at least in its current form, to assign side numbers 
and to apply the pins, nuts and washers (again, this is referred 
to as "nutology"). This limitation makes it less useful than if 
it were able to do so, but as stated earlier, it still shows an 
accurate depiction of where the aircraft actually are on deck. 

This is an important and successful evolutionary step of 
bringing the Ouija Board into the digital age. 

EATS also confirmed our theory that CCD cameras are good 
sensors to use to establish the four orientation parameters (X 
and Y coordinates, orientation and trajectory). Cameras have 
the advantage of being non-invasive (that is to say nothing need 
be done to the aircraft being "sensed") . This is imperative 
because coordinating concurrence by each of the different 
program managers for each of the different aircraft (E-14, S-3, 
C-2, etc.) would be very difficult. If a sensor or applique 
such as a bar code label or other identification tag were to be 
used, each individual aircraft Program Manager or PMA would have 
to be involved and would have to agree to the design or 
application. The engineers at Lakehurst assure us that the 
aircraft PMA's have been known to split hairs over the type of 
paint used on their aircraft. It would be exceedingly difficult 
to get a consensus if such a single sensor or label could even 
be identified. 

As mentioned in Chapter II, another consideration for 
aircraft mounted sensors is the power source. Some sensors, 
such as the lEE (Identify Eriend or Eoe) or Differential GPS 
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would only be useful when the aircraft was running on its own 
power (or on the Auxiliary Power Unit (APU) ) or when connected 
to ship's power (and the sensor system is turned on). There are 
even other considerations for emitting type sensors. These 
systems are "telling" the receiver on the ship where they are. 
An adversary able to electronically eavesdrop could exploit 
these emissions for his own purposes including targeting. An 
imposed Emissions Control (EMCON) condition would be another 
consideration. Depending on the level, all active electronic 
transmissions from the ship would have to cease. 

These same limitations would apply to a radio based system, 
such as the lEF currently found on all military aircraft. Here 
too, there are even more show stopping considerations. 
Differential GPS and lEE based systems would require more than 
one transceiver to accurately ascertain the target's relative 
position and orientation. If one of these transceivers was 
obscured or otherwise inoperative, the complete picture of the 
aircraft orientation might be lost. Furthermore, these active 
devices cannot relay configuration information, such as wing 
position, without some sort of additional equipment or methods. 

The EATS developers are also working on a camera system 
that would replace the ILARTS. We were able to observe some of 
the work on this system as well. The first impression was that 
the system uses a relative limited design that uses a pan-tilt 
CCD camera, similar to the cameras used on many U.S. highways. 

In our opinion the pan-tilt-zoom camera may be an excellent 
way to acquire the identification (which in turn provides the 
aircraft type) for the system. However, the trade off would 
appear to be a loss of visibility on the rest of the acres of 
flight deck as soon as the camera moved. 
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Our observations of EATS lead us to believe that it is 
advantageous to incorporate two design criteria into the Digital 
Ouija Board. The first is the use of more cameras. The second 
is to use a human to initially identify objects or aircraft for 
the system. The use of more cameras allows for complete 
coverage of the flight deck at all times. This ubiquitous 
coverage is required for the system to "know" where all the 
items of interest are at any given moment. 

The ILARTS system provides important information for safety 
and other considerations. The use of the pan-tilt-zoom camera 
for this application would appear to be appropriate since it 
specifically is looking at one aircraft at a time. It is 
conceivable that an EATS type of system could be used in lieu of 
the ILARTS system, but this is beyond the scope of this paper. 

The second design parameter highlights what we consider the 
advantage of the use of computers to enhance the human's 
abilities. Computers are exceptionally good of keeping track of 
the varied items in the cameras field of view. They can crunch 
the mathematical location information for the display based on 
the input from the sensors. Computers have a much more difficult 
time identifying objects, especially when the objects are at 
varied distances and orientations to the camera, and 
particularly when many of the objects are visually similar (from 
many aspects, the E/A-18 looks very much like an E-14) or when 
identical objects only vary by few distinguishing 
characteristics (such as the side number). We question the need 
for having the computer identify specific types or side numbered 
aircraft. Given that this system is being developed to enhance 
the human's ability to perform his or her job, it makes sense to 
have the computer track the objects but initially have the human 
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identify them. The current system uses human operators to 
provide this exact information. The introduction of a system 
such as the one we are proposing is not intended to replace 
personnel, but to increase their efficiency and aid them in 
decision making. 

The system should be able to know where a particular object 
or "target" is wherever it moves on the flight deck. Chce the 
target is identified, the system will then continually associate 
the identification of the target with its location track. This 
is analogous to the aircraft tracking system used by the FAA or 
CATCC. The system does not need to expend energy (and computing 
resources) revalidating the identification of the track once 
that identification is acquired. Should the system lose 
visibility or disassociate a track from its identification, the 
system could request the operator to revalidate, or re-identify 
the track. 

One possible method of how this could be done is to provide 
the "raw video" (the image the camera is actually recording) to 
the operator in a "screen in a screen" scenario, much like that 
found in many new TV sets. By simply popping up a raw video 
image of an aircraft, the user / operator is prompted to quickly 
re-identify the aircraft to the system. Once the track has the 
required identification, the raw video image window would close. 

The known processes of handling aircraft, as depicted in 
Figures 13 and 14, could be broken down into elements and used 
by the system to anticipate aircraft movement and notify the 
operator when actual activity deviated from what was 
(programmed) to be expected. 
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Figure 13 . 


Hangar Deck Operations Flow 



PibtedDT 
<lt<3rauc >/C 





A/CtvdlP 







A/Clutdk^ 



Inruh ^ 


_i 


Ctt Office A 

/ 

A/C (tee 

Vhi^ 


V7e^si& 

Bovd / 


ufoldior^ 

Oftcnoipfi-’’ 


teundi 

tJinBft-'. 


w«tg 



/ 

Fk.DkA<m 

itxyx 

djrpi^dfl 


/' 

Dnsrut 


/ 



front 

ADMACS 


&«u diipli^d on Ototionic Ou|4 Bo«d 
T>^ duplio>^ cn Bo«d 
1>«U dl^lcy^d on A/C U&iM Bocd 
I>) 1 & dupliorvd on Suftiau Bocd 
IN 1 » di$pk>^d on FDC W««(ion$ Bo«d 
DdA diipli^d on Ytllo'iff SIA Oo Bovd 
iNt* rgiut by ADUACS offion i\ PrvFV(by 
EATS mfiitun) 


. -^ 

KaitdUr \ 
ccdersA/Clo 
b« novel 




A/Cibovid 
to A/C 
E3evcoc 




ShpWH 


Onfrimc* 

Adut 


PoKon*! 

^ fxFDC 


rrpoctA/C 

WFNBov^ 


iMdiie 
tOBDlac S 


A/C>mv«nd 

pHOK^ 



Other Flight Deck Execution Activities 


Hekoopur 

oboird 


Ehtfiscvct 

onRlDli 

(AATlirt, 


Oftitf 

opcrdoul 

evttit$<nn. 

Dfc 


Coo^iciontf 

cyckc 

$po(toA/CQr 
ALREnurt 
mH" ^ 


V^(h- 

loultnove 

tonasuBw 


ftUlUvh 


Figure 14. Flight Deck Flow of Operations 


abi 

dat 

pos 


The D 
lity, j 
a from 
itional 


igital Ouija Board multi-camera 
ust as the current EATS system 
each camera. The data can 
coordinates or, as mentioned 


system would have the 
, to track and record 
be in the form of 
above, as a composite 


50 
























































































































































video display. But more importantly, the system would not only 
statically provide current object location and orientation, but 
also dynamically "remember" past object movement and compare 
this movement to the process model to anticipate possible 
conflicts. 

For example, if two aircraft needed fueling and were moving 
towards the same refueling station, the system could prompt the 
operator to direct the second aircraft to the next available 
station for simultaneous fueling as opposed to having the second 
aircraft wait. 


C. AVIATION DATA MANAGEMENT AND CONTROL SYSTEM 

Aviation Data Management and Control System or ADMACS is a 
first attempt to create a universal database for the use of all 
the flight support applications currently aboard US Navy ships. 
The following describes some of the functionality that is 
required for ADMACS^^: 

(ADMACS) will provide the Aircraft Launch and Recovery 
Equipment (ALRE) and air and flight operations (Air 
Ops) supporting work centers on aircraft carriers 
(CV/CVN class ships) and amphibious assault ships 
(LHA/LHD class ships) with a real time, fault tolerant 
(redundant), configuration managed, tactical Local 
Area Network (LAN) with an open system architecture in 
response to the emerging requirements to manage the 
data flow within and among these work centers and be 
the data source for information to be exchanged with 
other Command, Control, Communication, Computer and 
Intelligence (C4I) systems. An Evolutionary 

Acquisition (EA) approach will be used to facilitate 
fielding state-of-the-art systems capabilities keeping 
pace with evolving ALRE and Air Ops requirements. 
Within the ADMACS program, a number of acquisition 

20 Operational Requirements Document For Aviation Data Management And Control 
System(ADMACS) 
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phases will be in progress simultaneously. The ADMACS 
development and implementation will be divided into 
five increments. Each increment will be managed, 
funded, developed and tested separately and will 
comprise system(s) which contribute to the overall 
ADMACS development objectives and address the specific 
requirements of that particular user community. 

Surprisingly, the last sentence mentions how the different 
phases will be managed and funded, but nothing is mentioned on 
how the various phases will themselves be integrated. Neither 
is it articulated on how the Program Manager intends to get all 
of the adjoining systems to either conform to the data structure 
that the ADMACS is using or how ADMACS will eventually eliminate 
the need for all the other systems to acquire and store their 
own copy of the data. 

The ADMACS network is complete with redundant workstations 
for input should the primaries go down, UPS for continued power 
in the event of a power outage, and a thorough plan for the 
users to follow in the event of system problems. In order to 
better understand the data flow through the ADMACS system from 
the user perspective, an Input/Output Survey was made. Appendix 
D features this survey. The modest survey responses are in 
Appendix E. 

The network diagram in Eigure 15 shows the complexity of 
the ADMACS network and all of the workstations and different 
departments that it integrates to^i. 


Figure 15 is actually incomplete, for more of the network topology, 
reference the NAVAIR 51-15ABH-1-74 Operation and Maintenance Aviation Data 
Management and Control System (ADMACS) And Integrated Shipboard Information 
System (ISIS), section 003, pages 11 thru 17) . 
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Figure 15. Portion of the ADMACS Topology 


Our concern with ADMACS has less to do with the concept 
than with the actual implementation to date. We agree 
wholeheartedly that their needs to be a system that allows all 
of the various users in distinct locations, most remote to each 
other, to have complete data visibility. We have not found 
satisfactory reasons as to why the system has been so long in 
development and why, after nearly ten years, many of the needed 
features are still not included. The proposed Block II upgrade 
will, if developed as depicted, bring a great many more shops on 
line with the ability to interact. This is needed to provide 
data that others will need for their Plan-Decide-ACT (PDA) 
cycle. But as it stands, the only hard coding behind the Block 
II Upgrade is a 40 slide Power Point presentation that the 
engineers have pieced together in order to make the appropriate 
sales pitch to eventual users. 

The need for a total system has been established, 
unfortunately, there does not seem to be a clear set of 
requirements, provided by the OPNAV sponsor, for the engineers 
to write code and develop the tool. Further, the current 
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version of the tool is not widely deployed. A full deployment 
of the tool to all operational units would generate the feedback 
to improve the system with Block Upgrades, vice bring in 
additional capabilities that could have been included in the 
initial release. It appears that the developmental prototype 
was released for general use, a less than desirable scenario for 
software development. 

Additionally, the use of specific (out dated) hardware 
tightly coupled to the system will make it very difficult to 
expand the capabilities of the existing software. It also makes 
it difficult to implement the system on the ships that do not 
have the system yet or provide repair parts for installed 
systems because the original hardware is no longer manufactured. 
The Hewlett-Packard computer, currently used, has been out of 
production for several years. In the meantime, the systems 
command is apparently stockpiling available parts and retrieving 
older systems from Defense Reutilization and Marketing Office 
(DRMO) sites around the country. 

D. INTEGRATED SHIPBOARD INFORMATION SYSTEM 

The Integrated Shipboard Information System (ISIS) replaces 
the Plexiglas status boards used in Air Operations (AIR OPS), 
Carrier Controlled Approach (CCA), Primary Flight Control (PRI 
FLY) , and Flight Deck Control (FDC) with monitors and large 
screen displays. Officially, the ISIS is an integrated part of 
the ADMACS in that it uses the information from the other 
shipboard systems to acquire the information that it displays^^^ 

ISIS is an electronic data processing and display 

NAVAIR 51-15ABH-1-74 Operation And Maintenance Aviation Data Management And 
Control System (ADMACS) And Integrated Shipboard Information System (ISIS), 
section 003, page 3 
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system facilitating the timeliness and accuracy of air 
operations information provided to decision makers 
onboard CV/CVN class ships during shipboard flight 
operations. ISIS interfaces with other shipboard 
tactical, navigational and meteorological databases. 
Through ADMACS, ISIS enables rapid input; collection, 
processing and distribution of air operations data and 
the display of this information to all required ALRE 
and Air Ops work centers throughout the ship. 

As with ADMACS, most of the Fleet Carriers and Amphibious 
Assault Ships do not have the system yet. Our best information 
indicates that NAVAIR has spent over $74 Million on the 
development of the ADMACS and ISIS systems. The schedule for 
the deployment to the remaining ships is detailed in Appendix F. 
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IV. PEER-TO-PEER (P2P) NETWORK COMMUNICATIONS 


A. INTRODUCTION 

It is important to emphasize that the Yellow Shirt on 
flight deck is the Aircraft Carrier's best and most reliable 
sensor. What steps must be taken to connect the Yellow Shirt to 
the system that manages aircraft movement? 

It seems logical to push digital information to the sailors 
on the flight deck to increase operational environmental 
awareness. More importantly, if the system can request specific 
information from people in the environment, the accuracy of the 
operational picture depicted on the Ouija board will be that 
much better. 

Communication on the flight deck is primarily visual, but 
radios are also used. Emergent technology including hand-held 
devices and wearable computers could be used. As discussed in 
the introduction of this thesis, the more visual information 
provided to deck personnel, the better for the system. 

Ideally, the flight deck should be viewed and managed as a 
network. If each aircraft and each person is treated at a node 
on that network, the issues of facilitating communication and 
flow of information becomes a pure network management exercise. 
Primary network management issues that could be addressed in 
this context would be Bandwidth Management, Scalability and 
Mobility, Reliability, Communication Integration and Self- 
Organizing Behavior. 

Naval Postgraduate School, in association with the Joint 
Futures Laboratory, Joint Forces Command and the Joint 
Experimentation Directorate, conducted a Limited Objective 
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Experiment (LOE) to examine Peer-to-Peer (P2P) computing on 
hand-held and portable devices in a wireless network 
environment. The primary objectives of the experiment were to 
demonstrate the potential of wireless portable P2P computing 
technologies and explore how the technologies could impact 
operational Command and Control. Many of the findings generated 
as a result of the LOE can be directly applied to the flight 
deck communications solution. 

While it was outside the scope of this thesis to execute a 
limited objective experiment on flight deck communications, the 
P2P LOE findings did demonstrate that elements of network 
management should be taken into consideration when designing a 
comprehensive aircraft handling system. The system could be 
designed with future functionality in mind. Limiting system 
functionality to available hardware and software is 
shortsighted, considering technological advances. 

Peer-to-peer computing is the sharing of computer resources 
and services by direct exchange between systems. In a peer-to- 
peer architecture, computers that have traditionally been used 
solely as clients communicate among themselves and can act as 
both client and a server, assuming whatever role is most 
efficient for the network. This concept of computing isn't new 
(the idea is over thirty years old), but the emergence of faster 
computing power, larger bandwidth capability, and relatively 
inexpensive storage, warrants serious reconsideration. 

A recent example of successful P2P computing would be the 
universal file-sharing model or exchange of digital music files 
via the Internet popularized by "Napster". 

The P2P LOE at NPS used an urban hostage scenario and 
Reconnaissance and Surveillance Teams (RST's). The RSTs used 
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hand-held and portable wireless-enabled devices to build 
environmental and situational awareness. This awareness was 
used to augment the planning of a subsequent hostage rescue 
mission. 

B. NOC ROLE, P2P WIRELESS NETWORK BUILDING BLOCKS 

The main role of a Network Operating Center (NOC) is to 
manage and maintain network hardware and software. During the 
LOE, the NOC provided a high level of situational awareness that 
was fed to both the NFS Command Center and J-9 Headquarters. 
This awareness assisted the LOE team members to maintain 
consistent communications during the experiment, and to collect 
the experimental data. On the flight deck, the ability to 
maintain consistent communications is crucial. It is not 
unreasonable to envision an expanded role of the Elight Deck 
Control Center to include this type of network management. 

The research role of the LOE NOC was to explore the 
feasibility of bandwidth management for P2P collaborative 
application clients, scalability and mobility of collaborative 
network, integration of P2P with client-server communications, 
and feasibility of P2P collaborative network self-organizing 
behavior. The LOE NOC accomplished these research tasks by 
implementing various means of network configuration, 
performance, and fault management to observe network and 
applications behavior. 

The first step in managing the network involves developing 
a network model. The NOC manager begins the modeling process by 
creating or capturing the network topology. 
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C. SIMULATION, ANALYSIS AND RESOURCE ALLOCATION 

Once network topology is completed, a software simulation 
tool can be used to predict expected network performance. The 
simulation enables decision makers to predict efficiency and 
capacity of a proposed network before equipment is actually 
acquired. Simulation results also provide detailed information 
on network traffic and can differentiate, for example, the 
traffic attributable to the wireless segment of the network. 
Other useful performance elements include LAN load, throughput, 
data dropped, delay, media access delay, HTTP traffic sent, HTTP 
traffic received, HTTP page response time, and HTTP object 
response time. This data becomes crucial when allocating actual 
resources. The same date can be used to anticipate limitations 
that would impact operational success due to system reliability. 

D. MODELING, FLOW CAPTURE AND APPLICATION ANALYSIS 

Commercial products such as OPNET's Application 
Characterization Environment (ACE) Application can be used to 
capture packet data necessary to analyze application specific 
loads. Eiles and associated packet traffic is traced and 
documented to create an accurate model of network data 
exchanges. This data can be used to populate both the 
application layer and network layer views in CPNET. 

ACE can also be used to analyze the use of IP addresses. 
Dynamic Host Configuration Protocol (DHCP) provides a means to 
dynamically allocate IP addresses to computers on a local area 
network (LAN). The system administrator assigns a range of IP 
addresses to DHCP and each client computer on the LAN has its 
TCP/IP software configured to request an IP address from the 
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DHCP server. The request and grant process uses a lease concept 
with a controllable time period. 

In the case of flight deck operations, permanent IP 
addresses would be more appropriate than DHCP since there are a 
finite number of possible nodes on the ship (aircraft, support 
gear, sensor and people) . 

E. NETWORK MANAGEMENT SOFTWARE AND SNMP 

Products such as Spectrum Network Management Software 
enable NOC managers to "drill down" into the network and provide 
detailed views of the network at user-defined levels. Alarms or 
customized notifications can be established. System status 
changes can be indicated by a change in the associated component 
icon color (from red to yellow depending on the parameter). 
Various views of the network can also be customized including: 

• "Cablewalk" view: The layouts of the access points 
that are connected to the LAN. Detailed information 
about each access point can be viewed by double 
clicking the associated icon. 

• Device Topology. This detailed view displays each 

network component. A normal connection is represented 
by a green color. An icon will turn red if performance 
has fallen beneath a set parameter. A yellow icon 

will represent the component nearing the parameter. 

• Link State View. Each component will display a green, 
yellow or red color depicting the health of the link. 

Simple Network Management Protocol (SNMP) is the Internet 
standard protocol developed to manage nodes on an IP network. 

SNMP is not limited to TCP/IP. It can be used to manage and 
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monitor various types of equipment including computers, routers, 
and hubs. It is used extensively by Spectrum to discover, model 
and monitor a network. Active TCP connections can be monitored 
for any SNMP compliant asset on the network. 

F. NETWORK PERFORMANCE AND FAULT MONITORING 

Network management software can facilitate effective event 
tracking and system monitoring. The tools are versatile and can 
allow participants to see how activities might impact the health 
of the network. There are sufficient user-defined parameters 
and alarms that allow the NOC to shift assets to avoid hindering 
packet traffic during an operational scenario. Solarwinds 
Network Management System is commercially available software 
that can be used to monitor elements of network performance and 
faults. These elements include Network Performance, Current 
Response Time and Percent Packet Loss, Average Response Time and 
Percent Packet Loss. Information can be displayed graphically or 
in a tabular chart. 

Network performance and fault management can be monitored 
simultaneously. Elements of fault management that can be 
evaluated include: 

• Events and traps originating from wireless network 
elements. 

• Configured alarm parameter levels. Source, severity, and 
type are documented. 

• User-defined action scripts registered for certain 
alarm types or network element instances. Actions 
could initiate NOC manager notification through e-mail 
or pages (beeper). 
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alarm 


level 


• Color-coded hierarchy display for 
indications. Examples included minor (yellow), warning 
(cyan), major (orange), critical (red), informational 
(white), and decommissioned (blue). 

• Reported number and time distribution of selected 
alarms, alarm severity, alarm state, or network 
elements affected. 

NOC managers can determine alarm configuration and use the 
alarms to indicate network trouble before problems are actually 
realized. For example, if a network has severe packet loss 
between nodes, this would be clearly indicated and documented in 
the network, management software logs. Major alarms would appear 
if a node lost total connectivity from the network. 

G. BANDWIDTH MONITORING 

The bandwidth monitor feature of Network Management Tools 
provides a variety of display options. Information can be 
displayed either graphically or in a tabular chart format. 

The primary limitation of this function is that each 
network asset has to be SNMP compliant (Simple Network 
Management Protocol was discussed previously in section E of 
this chapter). In the example of the P2P LOE, only four of the 
six (laptop) terminals had functional Management Information 
Bases (MIBs), so Bandwidth capability could only be monitored on 
the servers. 

A MIB is a database of managed objects accessed by network 
management protocols. An SNMP MIB is a set of parameters which 
an SNMP management station can query or set in the SNMP agent of 
a network device (e.g. router) . 
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The SolarWinds TraceRoute module can also be useful in 
evaluating bandwidth usage. The utility will not only document 
the packet traffic paths taken from each node on the network, it 
also displays selected SNMP information about each device 
encountered. TraceRoute can be used to evaluate or query SNMP 
compliant machines outside the network. Packet response time and 
packet loss information can also be displayed both as a number 
and as a bar graph. 

H. P2P LOE FINDINGS 

Factors affecting overall performance of the LOE network 
appeared to focus on the application layer of the OSI model. 
Performance metrics were not consistent across all devices, but 
this could be attributed to location of the individual teams 
relative to the wireless access points or individual laptop 
application configurations with regards to processes running in 
the background on each node. 

The primary recommendation to improve application packet 
transfer would be coordinated turnkey configurations on each 
node of the network. Specifically, adjust the system 
configurations so there are minimal applications running in the 
background on the nodes. 

A mobile node should be able to monitor its own signal 
strength and bandwidth utilization. This was a critical form of 
operational feedback provided to the teams from the NOC. The 
result was the teams adjusted their physical location or changed 
applications being used on their devices. 

The experiment demonstrated the scalability of a wireless 
P2P collaborative networking, yet emphasized the network 
overhead needed to synchronizing voice over IP communication. 
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Voice packets were sequentially routed with other application 
packets, but the result was seemingly broken communication. 
Other traditional voice communication modes were more reliable. 
The data sharing features scaled-up effectively. 

The experiment demonstrated that P2P and Client-Server 
integration is feasible, but sensitive to roaming between the 
access point coverage areas. 

Application sharing was especially sensitive to roaming, as 
applications would drop when a team crossed a boundary of access 
point coverage. There was substantial packet loss until the 
application was restarted in the new area, so error checking and 
system synchronization/restoration features are necessary. 

Self-organizing behavior was demonstrated when 
Reconnaissance and Survey team members switched modes of 
communication due to signal loss or interference. Yet, the 
strongest (and unexpected) effect of self-organizing behavior 
emerged at the command and control center site when network 
center managers were able to effectively monitor performance and 
fault data, synchronize this data with the voice and data 
sharing calls, and adjust assets or operations before packets 
and connectivity between peers was lost. Essentially, new 
channels of communication between team members were facilitated 
in real time by the NOC monitoring team elements. 
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V. 


MACHINE VISION 


A. INTRODUCTION 

The biggest challenge in developing the conceptual design 
of the next generation Ouija board is formulating how action in 
a dynamic operational environment could be captured, processed, 
interpreted, summarized, and displayed for decision makers in 
"real time" or as action occurs. 

The technology is available to digitize the display of the 
Ouija Board, but simply replacing the physical templates and 
representative hardware with virtual icons will not be value 
added. The optimal solution would have to automate the capture 
and display of object location, orientation, and movement. This 
solution could share the summary operational picture and 
associated information with all the actors and stakeholders who 
contribute, interact, use or service aircraft in their jobs on 
the carrier. Further, the solution would have to help collect, 
collate, correlate, interpret, analyze, summarize and display 
all input from the systems that impact flight operations. 

The present Ouija Board is located in Flight Deck Control 
(FDC) . A decision maker can either call FDC and ask questions 
about the operational picture or physically visit FDC to see the 
static board. The optimal system would web-enable the summary 
display so the operational picture could be easily seen from a 
browser on any computer with access to the ship's network. 

A caveat to this project was that, when considering 
possible solutions, no hardware could be added to any aircraft. 
So we logically considered different sensors and methods for 
capturing the required information passively. As discussed in 
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Chapter 2 of this thesis, there are several commercial systems 
available for capturing object information. 


B. PASSIVE VISUALS SENSORS 

Aircraft location and movement information are currently 
captured and reported in the process described in the 
introduction of this paper. Human beings capture information. 
Therefore, for the purposes of this chapter, the proposed sensor 
component of the next generation Ouija Board will be compared to 
the human sensors currently used. 



Figure 16. The Human Eye^^ and the CCD Camera^^ 

The primary human sensor for capturing and reporting 
aircraft location, orientation, and status is primarily the 
human eye. As shown in Figure 16, the human eye and the 

Three-Dimensional Imaging Techniques, Takanori Okoshi, "Construction of the 
human eye" 

The CCD Camera portion of this illustration is from 
http://www.pulnix.com/imaging/pdfs/primer.pdf, PULNiX America, Inc., 

Industrial Products Division, "Introduction to "Video 101"" 
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standard Charge Coupled Device (CCD) or digital cameras have 
similar characteristics. The cornea protects the human eye 
while a glass cover protects the CCD. Each has a lens and an 
area to receive and interpret the ambient light reflecting off 
objects in the environment. The human retina has rod and cone 
cells that capture and encodes image data while the CCD has an 
array of pixels and either a horizontal or vertical shift 
register. The eye's data is transmitted forward via the optic 
nerve where the CCD transmits its data via fiber optic cable. 


C. LANDMARKS AND SENSOR LOCATION 


Where could passive sensors be located in the operational 
flight deck or hangar bay environment? During the data 
collection visit to USS TRUMAN (CVN 75), the authors noted the 
symmetrical location of all the aircraft securing points 
(padeyes) on the flight deck as illustrated in Figure 17. 



Figure 17. Aircraft Securing Points (Padeyes)25 


As discussed in Chapter II, visual or pressure sensitive 
sensors could be installed in each of the padeyes on deck, but 

This illustration was compiled from actual ship's drawings for the 
Nimitz class Aircraft Carrier. 
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the initial installation, associated wiring, and subsequent 
required maintenance would be cost-prohibitive. Also, these 
sensors would only be able to look up at the bottom of an object 
or sense pressure when an object was actually upon it. 


The primary benefit of noting the symmetry of the padeyes 
in the flight and hangar deck is that the padeyes can be used as 
landmarks or reference points to assist in localizing where an 
object is on the deck. 
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Figure IS 


Flight Deck Lights^ 


The symmetrical location of all lighting fixtures as 
illustrated in Figure 18 above as well as the flood lamps used 

26 NAVAIR 51-50AAA-1 003 00, Change 3-1 February 1999 Page 3. "Typical VLA Lighting 
Arrangement (CV/CVN)" 
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to illuminate the flight and hangar deck is also useful. In 
most cases, there is room either in the light fixture or on the 
light mount to support an added sensor. Even if the light 
fixture won't support the extra sensor, the sensor could use 
that light power cable. 



For example, a CCD camera could be mounted in the wheel 
stop coaming at the deck-edge as depicted in Figure 19 or 
mounted below a floodlight high on the island as shown in Figure 
20 . 



Figure 20. CCD Camera Mounted Below a Floodlight^^ 


27 This figure was based initially on the Deck Edge Light Assembly 514610-1 
(Sheet 1 of 2) in NAVAIR 51-50AAA-1 004 00, 

28 Based on the Floodlight Assembly (PAR 56) 506829-1 (Sheet 1 of 3)NAVAIR 
51-50AAA-1 006 00, Change 2-1 November 1995 
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D. 


INTEGRATED FIXED FIELDS OF VIEW 


Once cameras are strategically mounted, the various fixed 
fields of view can be analyzed and then integrated with other 
fields of view to systematically pinpoint dominant 
characteristics of the individual objects in relation to the 
fixed landmarks on the flight and hangar decks. Individual 
pixels in each fixed frame could be referenced to the fixed 
padeyes or deck lights introduced previously. If an object is 
near a known landmark, the system could interrogate the fields 
of view from corresponding cameras as shown in Figure 21. 



Figure 21. Integrated Fields of View 


For example, if a fixed camera on the island recognizes an 
aircraft in its field of view, the system will know which 
general area the object is in. Line of sight from the island 
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camera will queue the system and estimate object location on a 
deck Cartesian coordinate grid as shown in Figure 22. 



Figure 22. Flight Deck Cartesian Coordinate System 



E. OBJECT HANDOFF BETWEEN FIELDS OF VIEW 


Another theory to reduce processing requirements could be 
methodology similar to cellular phone service. A cellular phone 
customer talks to a colleague on the phone while he drives down 
a highway. 





Figure 23. Cellular Signal Hand-off^® 


As shown in Figure 23, the call is initiated on the cell 
antenna with the strongest signal. As the caller proceeds down 
the highway, the signal to the first antenna becomes 

Graphics adapted from http://www.howstuffworks.com/cell-phone2.htm, June 

20 , 2002 
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the 


same 


signal 


is getting 


progressively weaker but 
progressively stronger at the second antenna. 

Each antenna along the highway monitors signals within its 
range. The system determines when the signal is switched to the 
subsequent antenna. Seamlessly and without apparent signal 
interruption, the phone conversation is continued, but the 
signal is now from the second antenna. 

The signal hand-off from antenna to antenna in the cellular 
phone example is an excellent analogy for how passive video 
cameras can be integrated. 



Figure 24. Field of View and Object Hand-off 


As an object moves from field of view to field of view, the 
intelligent agent proactively monitoring an objects location and 
orientation will activate or capture the object in more than two 
cameras. 

Two things can occur at this time. The system can then 
determine orientation of the object and identify both the 
visible and the unseen landmarks to determine the x and y 
coordinate and/or interrogate the appropriate camera, camera 1 
in this case, as shown in Figure 24 above. 

















































In order to reduce latency, the system could reduce the 
processing required to resolve that an aircraft has entered 
camera I's field of view as opposed to processing all fields of 
view where the aircraft isn't. Because the camera is 

perpendicular to the flight deck, the exact "x" coordinate of 
the leading edge of the object could be pinpointed. The system 
could then use this information to minimize the processing 
required on other images in relation to this object. 
Specifically, if the object is an aircraft with known 
characteristics and dimensions, only the effected portion of 
each of camera 2 and camera 3 images has to be interrogated 
and/or resolved. Because the fields of view are fixed and the 
dimensions of the aircraft are known, the overlapping fields of 
view will require less processing to confirm the location of the 
object. 


F. FUNCTIONALITY DISCUSSION 

For the purposes of this thesis, 30 frames per second will 
be sufficient to all the system to not only process but also 
integrate fields of view from several cameras. Considering how 
quickly a processor operates, time is essentially stopped for 
that 1/30^'^ of a second. Because the computer can process 
information so quickly, results are theoretically displayed in 
"real time". 

Real time describes a human rather than a machine sense of 
time. It is a level of computer responsiveness that a user 
senses as sufficiently immediate or that enables the computer to 
keep up with some external process. 

While it is outside the scope of this paper, simultaneous 


and parallel processing of images is possible and supports the 
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concepts of processing information in a complex environment in 
real time. 

The real power of image processing and image integration 
initially includes the ability to subtract fixed portions of an 
image to isolate only those things that have changed or moved. 
The next is the ability to resolve images by comparing offset 
images. 

This flexibility will facilitate the vision of reduced 
manned ships and possible limit the staffing needs on deck. In 
a future system, the aircraft on deck will either be remotely 
piloted or will have handlers directions to the pilot fed via 
data link to the pilots Heads-Up Display. 

A very sophisticated system could differentiate between an 
aircraft and the technician riding a wing while the aircraft is 
towed to a new location? 

It is conceivable that intelligent agents responsible to 
track the human could not only determine specific x - y 
coordinate, but triangulate the z coordinate (distance above the 
deck) as well. 

Limb and torso orientation of the humans on the flight deck 
could also be discerned and considered in the decision support 
system as depicted in Figure 25. There is software available to 
track the exact orientation of the eyes, but this type of 
recognition currently requires dedicated cameras and a constant 
monitoring. Since flight deck personnel wear protective eye 
coverings, the most efficient method for this level of 
observation would be sensors inside the individual goggles. 



How much detail? 
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COME AHEAD STOP/APPLY BRAKES HOLD 

Figure 25. Actor Rendering and Hand 



Signals^^ 


The system could interpret hand signals and body 
orientation. Then the system could anticipate a conflict and 
either notify a yellow shirt of a potential conflict or safety 
notification and give the handler updated information to adjust 
directions to the pilot or directly countermand the pilot over 
the tower radio. 

This level of effort can result in heightened situational 
or environmental awareness. The system could interpret the 
orientation information of the actor and use that data to prompt 
that or another actor to beware of or look for potential danger 


Adapted from Aircraft Signals NATOPS Manual, NAVAIR 00180T-113 
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(i.e. look right, jet turning, jet blast envelope will cover 
your location). 



As shown in Figures 26 above and 27 on the next page, jets 
exhaust temperatures and velocities parameters for all the 
various aircraft on deck can be cataloged in a system database. 
Idle through military power variations could be considered by 
the system and used to prompt actor notifications when potential 
conflicts were determined. 


Adapted from NATOPS Flight Manual Navy Model F-14A Aircraft, NAVAIR 01- 
F14AAA-1 
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Figure 27 


Exhaust Temperature and Velocity^^ 


Adapted from NATOPS Flight Manual Navy Model F-14A Aircraft, NAVAIR 01 
F14AAA-1 
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G. PROCESSING REQUIRMENTS 

When processing images, the first image is the default 
image (IMd) . All known fixed portions of that image will be 
immediately subtracted to streamline the bandwidth and 
processing requirements. This process could almost be completed 
at the camera itself. 

The camera could be as basic as possible. Varying light 
might become a factor in the operational environment, but a 
camera with a fixed aperture and fixed lens with the minimal 
moving parts will result in less maintenance and higher 
reliability. 

Software will be the determining factor using this 
strategy. For example, if the CCD has to be exposed for 1 
microsecond for normal light, it may need up to 3 microseconds 
for the same equivalent exposure in low light. The longer 
exposure may cause blurring depending on what is moving and how 
quickly objects are moving in that frame. 

The simple camera will have to work in intense and low 
light situations. Although cost will be a factor that will 
impact the final number and type of cameras used, operational 
flexibility and system reliability regardless of the ambient 
light will inevitably cause the organization to use cameras with 
Infra Red (IR) spectrum capabilities. 

The CCD camera can take up to 30 individual images of the 
same scene every second, but for that 1/30-second, time stops. 
All cameras feed their respective image to fill their portion of 
the panoramic view of the flight deck. 

The system, for example, would allow the Commanding Officer 
of the ship to move a virtual frame anywhere on the flight deck 
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using his browser and computer. Figure 28 illustrates a 
possible camera numbering, positioning, and integration scheme. 
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Figure 28. Camera, Position, and Integration Scheme 


A joystick and frame icon over the silhouette of the ship 
would let the operator focus on any part of the deck. Possible 
functionality would include freeze frame, replay, and enhanced 
capture for safety and mishap situations. 

Parallel systems could tap specific camera feed for 
detailed streamed video in real time. A second system could be 
used for instant replay. A third could examine and anticipate 
movement and conflict information. 

In a fixed microsecond, assuming the ultimate system could 
effectively capture, integrate, and store up to 30 panoramic 
images per second from fifty cameras, each camera required one 
Meg of memory or 50 Meg per panoramic shot and 1500 Meg per 
second. 

A significant archiving capability would be required. 
While permanently archiving one hundred percent of the raw video 
is impractical, appropriate rules could be established to 
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archive significant parts of the raw footage that would document 
fires, crashes, and other casualties. 

Another alternative is to determine if virtual simulation 
based on the real time rendering of objects when reenacting 
events that led up to a catastrophe would be acceptable. 

H. ALTERNATE SENSOR LOCATIONS 

The optimal placement of sensors is yet to be determined. A 
single camera that could resolve the entire flight deck would be 
the easiest scenario, but that sensor would have to operate in 
all ambient light and weather conditions. 

Two potential strategies could be Unmanned Aerial Vehicles 
(UAVs) or Mast Mounted sensors. 



The UAV featured in Figure 29 is the Aerosonde by Aerosonde 
Robotic Aircraft Ltd. The UAV is a small robotic aircraft 
developed primarily for long-range environmental monitoring and 

Graphic features the 'Aerosonde'. Illustration by Aerosonde Ltd. at 
http://WWW.aerosonde.com 
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surveillance. It has been developed especially for 
meteorological and environmental reconnaissance over oceanic and 
remote areas and in harsh conditions. Its economy and 
flexibility allows routine operations on a much wider scale than 
has been possible in the past and could possibly take station 
above the flight deck of a carrier. It has been extended to 
surveillance and other reconnaissance applications already. 

The Aerosonde is being deployed to fill chronic gaps 
in the global upper-air sounding network, to conduct 
systematic surveillance of tropical cyclones and other 
severe weather, to undertake offshore surveillance and 
agricultural/biological surveys, and to obtain 
specialist observations, such as volcanic plumes. 

This $50,000 gasoline engine UAV would normally operate at 
an Altitude of 20,000 feet and could travel as far as 
approximately 1800 nm. On station time is approximately forty 
hours with a cruise speed of 70 mph and a maximum speed of 85 
mph. The optimal altitude and speed need to be determined. 
Slow flight characteristics were not available. 

Limitations of this platform would be payload and 
bandwidth. Flying directly over the ship between two and three 
hundred feet would allow a CCD camera to effectively see all 
activity on the flight deck through one lens. Depending on 
optical characteristics, more than one camera would be 
warranted. An effective line of sight, high frequency signal 
would be required to relay the operational picture. 

Sensors and required hardware to keep the UAV autonomously 
on station plus transmit the streamed video of the flight deck 


http://www.aerosonde.com, June 20, 2002 
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might impact the endurance of the UAV. Hardware and software 
needed to process the video should remain on the ship. 

An advantage of the UAV directly above the ship is it could 
be used for passive surveillance of the surrounding area 
simultaneously with the flight deck. A disadvantage of this 
scenario is that an enemy might use the UAV to locate the ship. 

The new CVNX class carrier will feature a smaller island 
with less radar cross section. A single mast with mounted CCD 
cameras would still be feasible. The mast would have minimal 
radar cross-section, yet simplify the challenge of capturing 
large quantities of streamed video feeding optical cable through 
the center of the mast. The lightweight cameras as featured in 
Figure 30 could be mounted high enough above the deck to allow a 
comprehensive operational picture. 



Commercially available hardware and software could be 
integrated with appropriate sensors on the flight deck to 
passively capture all object movement on the fight deck. 
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VI. USE OF AGENTS 


A. TERMINOLOGY 

Agents are programs that are able to respond to their 
environment and that have some effect on the environment by 
their actions. They carry out a task unsupervised, so they are 
characterized as autonomous. Intelligent agents take this one 
step further and apply some degree of what is termed 
"intelligence" to a task. The intelligence may be minimal but 
often will incorporate a degree of learning from past 
experience. 

There are many ways in which software can learn. Two of 
the current technologies used for this are Neural Networks, and 
Case-Based Reasoning. 

A neural network is usually an analytical tool that is 
designed to function the way neurons in the human brain receive, 
process, store, and communicate knowledge. Used to solve 
problems that typically defy formula-based analytical methods, 
neural networks produce answers based entirely on empirical 
evidence, or in human terms, through experience. This occurs 
frequently when there are large numbers of variables involved in 
the consideration of any one action in the model. The advantage 
to Neural Networks is that the software is adaptive or it has 
the ability to learn from experience. This is accomplished by 
programming a finite number of variable parameters that have 
distinct results in the initial program. The system is then 
able to use training algorithms in the following way^^: 


http://www.statsoftinc.com/textbook/stneunet.html, June 20, 2002 
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Neural networks learn by example. The neural network 
user gathers representative data, and then invokes 
training algorithms to automatically learn the 
structure of the data. Although the user does need to 
have some heuristic knowledge of how to select and 
prepare data, how to select an appropriate neural 
network, and how to interpret the results, the level 
of user knowledge needed to successfully apply neural 
networks is much lower than would be the case using 
(for example) some more traditional nonlinear 
statistical methods. 

The use of neural networks is appropriate when any 
relationship between input variables and output variables 
exists, even when that relationship is very complex. They are 
"best used" for fault diagnosis and event correlation due to 
their efficient pattern recognition properties. They typically 
are used when there is a deep understanding of their domain. 
Additionally, they are an effective alternative when other 
methodologies fail. Neural networks are able to handle 
incomplete, ambiguous and imperfect data. This has considerable 
implications for our real-world application since it is 
realistic to predict that the standard mode of operation 
includes imperfect information. 

Case Based Reasoning (CBR) is another methodology that is 
used to enable software to "learn". Case-Based Reasoning makes 
use of a library of solutions to known problems. The obvious 
issue here is what will happen when the library does not contain 
the answer to the question or problem at hand. This, in fact, 
is the single largest drawback to CBR^^. Nonetheless, CBR is 
effective and has the following advantages: 


Along Lin, Hewlett Packard Labs, Feb 1998, A Hybrid Approach to Fault 
Diagnosis in Network and System Management; page 2, 
http://WWW.hpl.hp.com/techreports/98/HPL-98-20.pdf 
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• While there are many other methodologies that may be 
it can solve problems within partially understood 
domains. 

• It can reason by analogy efficiently. 

• It can learn from new cases. 

• Its knowledge representation is less restrictive. 

• It allows faster knowledge acquisition. 

• It can evaluate a proposed solution. 

It is considered beyond the scope of this thesis to 

determine which methodology is most appropriate for use on the 
Digital Ouija Board. We merely mention it here to afford the 
reader a better understanding of what is meant by the concept of 
software that is able to "learn". 

B. WHAT AGENTS CAN DO 

The adaptive properties inherent to agents make them ideal 
for the use in this endeavor. Assuming the next generation 

Ouija Board and Air Department Data Management System proceed 
without a complete overhaul or consolidation of the many 
different databases, agents could be used to integrate the 
legacy parts. They could be used to locate, input and retrieve 
data from various systems. The "learning" would be useful in 

that the agents would be able to determine data paths and 

formats from previous "experience". This would benefit the 
system by the increased efficiency in which the agents are able 
to read, write and display pertinent information from dissimilar 
programs or databases. 
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Use of agents is attractive because they are able to 
perform tasks for the user that greatly enhance the user's 
ability to work ef fectively^'^. Agents are always available and 
can act as the user's proxy in predetermined routine tasks when 
the user is otherwise engaged. When one considers the vast 
number of activities associated in everyday operations aboard 
the carrier, there is simply too much information for the humans 
involved to adequately monitor. An agent can act and react to 
situations quicker than the user could because an agent is able 
to observe its environment completely all of the time. It is 
not subject to human inattention or loss of focus. This 
thoroughness allows an agent to perform repetitive tasks without 
getting bored. Agents are also flexible. They may be 

specifically designed to adapt to changing circumstances or user 
preferences. 

Some intelligent agents can also interact with one another. 
There is considerable research in this area, with many exciting 
possibilities. Some of the attributes of an intelligent agent 
are listed^^: 

• Autonomy: agents operate without the direct 

intervention of humans or others, and have some 
kind of control over their actions and internal 
state 

• Social ability: agents interact with other agents 
and (possibly) humans via some kind of agent 
communication language 

• Reactivity: agents perceive their environment 

(which may be the physical world, a user via a 

Ian Dickinson, July 1998, Human-Agent Communication 

Bjorn Hermans, Thesis for the Tilburg University, Tilburg, The Netherlands, 
the 9th of July 1996, Intelligent Software Agents on the Internet: an 
inventory of currently offered functionality in the information society & a 
prediction of (near-) future developments; section 2.2.1 page 15 
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graphical user interface, a collection of other 
agents, the Internet, or perhaps all of these 
combined) , and respond in a timely fashion to 
changes that occur in it. This may entail that an 
agent spends most of its time in a kind of sleep 
state from which it will wake if certain changes 
in its environment (like the arrival of new e- 
mail) give rise to it; 

• Pro-activity: agents do not simply act in 

response to their environment; they are able to 
exhibit goal-directed behavior by taking 
initiative; 

• Temporal continuity: agents are continuously 

running processes (either running active in the 
foreground or sleeping/passive in the 
background), not once-only computations or 
scripts that map a single input to a single 
output and then terminate; 

• Goal oriented-ness: an agent is capable of 

handling complex, high-level tasks. The decision 
how such a task is best split up in smaller sub¬ 
tasks, and in which order and in which way these 

sub-tasks should be best performed, should be 
made by the agent itself. 

These attributes are a lower level view of what an agent 
can do if properly designed and implemented. 

The Digital Ouija Board has three distinct areas that will 
benefit from different sets of these properties. These are 
discussed in detail later in this chapter. 

As previously mentioned, the Digital Ouija Board needs to 

enhance the current systems' capabilities and increase 

functionality of the existing Ouija Board from a static display 

to an integrated decision support utility. This has widespread 

applications for future operations on aircraft carriers, and 

might conceivably impact operations of the battle group or even 
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higher. In order to realize this potential the system must make 
full use of all the data that is currently gathered, but not 
necessarily readily available. One of the major systems goals 
for the Aviation Data Management and Control System (ADMACS) 
Block II upgrade is to integrate all of the disparate, 
"stovepipe" systems so that all the data is shared across 
systems to give the users the complete data visibility that is 
required^^. Since the data used in the aforementioned systems 
was developed by-and-large as stand-alone systems, little 
consideration was given to a consistent data structure. In 
order to accommodate future integration of these systems, there 
needs to be a way to interface with other systems data, such 
that new functionality will not interfere with the established 
processes. 

Interviews with the researchers at Lockheed's Advanced 
Technology Laboratories (ATL) have confirmed that when unknown 
or varying data structures exist it is the ideal situation to 
use agents. Their assertion is that agents are only concerned 
with the actual data and not the data structure. Furthermore, 
agents have the added benefit of speeding up database processes, 
which is counterintuitive. It is logical to assume that an 
additional layer of obscuration would cause the system response 
times to increase. Apparently, agents are able to decrease 
response times for data manipulation. The explanation for this 
is summed up in the following quote by one of the ATL 
researchers: 

...a mobile agent is basically a software program that 
can transfer itself to multiple machines while 
executing. Thus, it has the ability to transmit code 
to another machine, such as the case of a query to a 
database for some specific item. The code is the 

ADMACS Program Block Upgrade PowerPoint presentation from NAWC Lakehurst 
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logic to find the right item in the (database). Since 
the logic to select the proper item is brought to the 
machine, the agent can continue to search, while local 
to the database, rather than transmitting data 
multiple times while searching for the proper 
(database) entry. Basically, the cost is the one time 
travel of the agent code versus the cost of multiple 
transmissions of data as in a remote query. Thus, in 
contrast to the client-server model, this provides a 
beneficial bandwidth savings. 

In essence, the agent is able to precipitate a distributed 
computing scenario where more than one machine (or processor) is 
working on a particular problem. Thus it appears that the use 
of agents for the interactions across the multiple legacy 
systems may be not only appropriate, but also potentially very 
beneficial. 

This benefit is fortuitous since we feel it is unlikely 
that a complete overhaul of all the existing systems will occur 
in the short-term. We firmly believe that there are other 
mitigating circumstances that would suggest that the complete 
overhaul of the existing systems would be an optimal solution. 
Our opinion is based on the observations that we have made on 
how individual programs today are managed with little, if any, 
regard to how their piece of the puzzle fits into the "big 
picture". The primary problems will all come back to the scope 
and funding of these individual systems. 

These legacy systems exist as a product of individual 
"solutions" devised to answer specific needs. This appears to 
have been a prevalent approach to application authoring from 
fifteen years ago. For example, no one wanted an office suite 
that did word-processing, spreadsheets, database and 
presentations - indeed; no one even fathomed all of these things 
together. Yet, integrated "products" would become the standard 
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way that most everyone purchases office automation software 
today. The benefits of an integrated suite of programs are that 
the parts are designed to work together. If they did not, 
customers would not be enticed to purchase an integrated product 
that was less capable than the individual parts. 

The issues with the current stovepipe systems are that they 
are predominantly dated systems that were only designed to 
address the original users' concerns. It is difficult and 
costly to keep many of these hardware-dependant systems 
functional. We did not observe any attempts to validate the 
dated requirements that these systems where originally designed 
to address. We did observe engineers writing requirements for 
what the updated system ought to be. Clearly, this is a case of 
the tail wagging the dog. The "Fleet" users should be telling 
the engineers what is needed, not the reverse. A more effective 
requirements modeling process is needed. 

Another observation is that the requirement to make the 
data available for other systems to use was apparently not 
considered. Therefore, we endorse an approach that would 
require a bottom-up requirements review that clearly defined the 
needs of all of the Air Departments (Flight Deck Control, CVIC, 
Weapons, Fuels, the squadrons. Air Ops, Pri-Fly, etc.). These 
"needs" could readily translate into data fields in one master 
database and would conveniently facilitate visibility that we 
assert is needed in order to realize the efficiencies discussed 
in this thesis. As previously mentioned, our "B Plan" would 
utilize the existing systems as they are with agents enabling 
the interconnections between the systems. 

There are other aspects to the overall data / knowledge 
management issue described in this thesis. The use of agents 
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for the control of and integration of the sensors is seen as the 
enabling technology. Our intention is to further describe how 
agents could be used to facilitate this and other vital 
functions. 

Lockheed Corporation has done extensive research and 
development in the field of software agents and has categorized 
them into three distinct groups^°: 

The Advanced Technology Laboratories developed 
generalized notions of three of these capabilities: 
information push or agents automatically send 
information to other agents or entities that may need 
it; information pull, where agents retrieve relevant 
information from distributed sources; and sentinel 
monitoring, where one or more agents persistently 
checks for an event or existence of a condition and 
reacts to its occurrence. 

This agent classification is descriptive of what we 
envision the new system of systems routinely executing. Agents 
are able to provide database connectivity when users require 

information. They also may be used to retrieve data 

automatically and perpetually, modify date if required, and 
display summarized data in the appropriate form. 

Lockheed discovered that they could use the agents to make 
complex queries from disparate databases. In fact, they found 
the use of agents to be beneficial to this activity since the 
agents allowed them to specify what they called "high level 

concepts" vice exact database schemata^^. The applicability for 
the Digital Ouija Board is that this ability will permit the 
interactions of the system with existing legacy / stovepipe 

systems without regard to the data structure. 

Susan McGrath, PhD; Daria Chacon; Kenneth Whitebread, PhD; Intelligent 
Mobile Agents in the Military Domain, pgs 1-5 
IBID 
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The sensor portion of this project could also benefit from 
extensive use of agent technology. Current efforts to provide 
sensor fusion focus on bringing radar, infrared (FLIR) and other 
combat systems information together in order to provide enhanced 
target tracking. This same weapons application logic could be 
ported for the use of multiple, but similar sensors tracking the 
same information, but from different vantage points. This 
fusion would enable multiple sensors (presumably CCD cameras) 
with different fields of view to correlate their images, or 
tracks; to verify that what one camera "sees" is the same 
aircraft that another camera is tracking. This merged data not 
only enforces the certainty that a track is correct, but it 
works integrally with the display agent responsible for 
depicting the correct track information on screen. 

Another important research effort sponsored by the U.S. 
Defense Advanced Research Projects Agency (DARPA) is the Control 
of Agent-Based Systems (CoABS). This research program has 
classified four distinct agent type of particular interest to 

the military^2. 

...those that are aimed at complex problem-solving; 
those that find, filter and present information for 
users; those that provide services to other agents to 
help them cooperatively solve complex problems; and 
those that provide translational services between 
agents using different standards, communications 
protocols, languages, etc 

The proposed system would be a large-scale effort in terms 
of size and complexity. It remains to be seen if the actual 
number of agents to enable such a multifaceted system would be 
considered a large-scale effort by DARPA's standards. There may 
only be a relatively small, finite number of agents that are 
^2 ibid 
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however 


needed, 
extensively 
objects and 


these few agents would likely be reused 
throughout the system since there are many similar 
redundant actions associated with aircraft handling. 


In concept, the system could be comprised of interacting 
agents from all four groups, and could offer new capabilities 
that are now beyond the realm of traditional software design. 
The system will require a dynamic infrastructure that could 
provide these capabilities and would purposefully direct 
software developers to design smaller pieces of code that would 
primarily function on solving problems through mutual 
interaction, rather than independent systems duplicating 
functions that are better provided by other programs or by a 
hybrid system. 

The Digital Ouija Board could make use of many common 
components, thus keeping it aligned with other military 
applications, as described by the Lockheed group. The 
significance of this should be emphasized since we are 
endeavoring to automate a system that has been in existence for 
over fifty years. The operators will want assurances that the 
technological solution is sound, tested and reliable. Using 
tried and true components, we are able to assuage some of their 
initial fears. 


An added benefit to the Navy is to discover which 
commercial elements are working in the field of agent 
development so that they may be consulted on work like this, or 
for other systems. Our discussions with the ATL make it 
abundantly clear that ATL is a prime candidate for 
consideration. 


In order to maximize the Digital Ouija Board's utility for 


as many users as possible it will have, or at least should plan 

95 



future expansion to include, the capability to interact with 
multiple users as "targets" or "actors". What is meant here is 
the aircraft director on the deck or the yellow gear driver will 
be able to receive information from the system to alert them to 
a particular condition. In the safety realm, this could be used 
to alert actors of an impending collision or an individual actor 
who is about to walk into a danger area (turning propeller, or 
jet blast zone) . To facilitate this type of functionality, the 
system might use what Lockheed has labeled an Information Push. 

Developed for DARPA's Small Unit Operations (SUO) program, 
the "Information Push" was created to enable the system to first 
locate an individual actor, and then push critical information 
to that individual, team members, or higher echelons directly 
above the actor in order to prompt a critical response (be it an 
answer to a query or a warning to the individual). Other agents 
work in tandem with the push agent to optimize the operation. 

An Analysis Agent determines who needs specific 
information. This feature ensures proper delivery yet minimizes 
the bandwidth requirements for the notification by eliminating 
traffic that is not required, compared to a more general 
multicast transmission. A Delivery Agent is employed to keep 
track of the nodes, actors and delivered information. If the 
delivery agent determined none of the targeted actors received 
the message, it can activate an additional agent or initiate 
additional actions that would perform a contingency action as 
needed. 

We envision the following scenario as a graphic 
illustration of how this all works: A yellow shirt directing an 
aircraft while another flight deck crewman inadvertently walks 
into the path of a moving aircraft, or turning propeller. The 
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"safety watch" capability of the system could anticipate the 
conflict and respond by activating a specific agent programmed 
to immediately notify that crewman of the impending conflict. 
The analysis agent would determine who needs the information and 
the delivery agent would ensure the message was delivery to that 
individual. Should the delivery agent sense a delivery failure, 
another agent is activated that would elevate the warning and 
attempt to deliver it to other crewmen near the at-risk crewman? 
In the event the crewman is still not responding, another agent 
would notify the Air Boss to direct his attention to the 
imminent problem. 

This type of agent use looks promising for the type of 
scenario described. There are countless other uses for this 
technology, especially as more flight-deck personnel are 
connected to the communications and information network, either 
via headsets, PDAs, or other wireless computing devices that 
would enable alerts or notifications. 

Since the proposed system is primarily interested in 
tracking the position and movement of a fixed number of aircraft 
and displaying associated information, we must consider the 
timeliness of any information system that must be real-time. 
Ideally, we want to be able to track more than just the 
aircraft. The system has considerable safety applications that 
will be most effectively realized only when all objects on the 
deck are tracked; aircraft, people and support equipment. 

Now the problem of system updates for real-time display 
plus the added requirements that multiple agents making 
countless data calls to many independent databases becomes much 
more significant. The system must take the throughput. 
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bandwidth, storage, memory and processing capabilities into 
consideration. 

A factor here will be to what extent these multiple 
software agents have on the performance of the system as a whole 
as it relates to the aforementioned constraints. This problem 
is not unique to our proposed system and has been investigated 
by the CoABS project. Their findings indicate that a system can 
use upward of ten thousand agents before realizing any 
performance degradation. Furthermore, only a minimal 

degradation was observed as the number of registered agents 

increased^3 ^ 

In many agent applications, one of the compelling reasons 
that an agent will visit a computing node is to utilize the 
resources at that node. There are three important points to 
note. First, to conserve bandwidth the system should migrate as 
little code with an agent as possible. Second, the code or logic 
needed to exploit the resources at the node will usually be the 

same for all agents. Finally, it is desirable to separate the 

implementation of these resources from the implementation of the 
agent application. 

The researchers at ATL describe an environment with 
existing nodes as being a primary consideration for the 

application of agents. As such, the current "system" aboard US 
Navy ships for the Ouija Board, and for the larger "system" 
which includes all of the associated Air Ops data systems (be it 
a computerized system, a grease board or a clipboard) appears to 
be the perfect candidate for the application of agent 

technology. 

43 Martha L. Kahn and Cynthia Della Torre Cicalese, CoABS Grid Scalability 
Experiments, pg 1 
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Consider an agent-based database application where the data 
resources are distributed among several computing nodes, as 
depicted in Figure 31. In a heterogeneous database environment, 
the code needed to query a database will not be the same at all 
the nodes. In fact, the actual implementation of the databases 
at these nodes may be changing. In such situations, it is better 
to package the code needed to access these resources into a 
separate component, which remains at the node, known as servers. 
It is beneficial to have a common interface between the agents 
and the servers that offer similar services at different nodes, 
even though the servers may differ in their implementation. This 
keeps the agent machine-independent. 



Figure 31. Agent Distributed Amongst Nodes 

As previously mentioned, one of the benefits of using 
agents is that they are schema independent. This is 
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advantageous since information is the aspect of the database 
that users are primarily interested in, not the format of the 
data. Agents, therefore, are able to reuse their code to 
extract data from different types of databases without having to 
know anything about the individual schema. 

Figure 32 illustrates an agent performing a database query 
at one node hosting a DB-2 database and then migrating to 
another node hosting a Microsoft Access database. 



Figure 32. An Agent Performing a Database Query'^'^ 


The agent uses the same interface on each server to 
execute a database query even though the server's 
implementation is different at the two nodes. We can 
now piece the agents, tasks and servers together. An 
agent executes a task at a node. The task may access 
servers to exploit resources at that node to achieve a 
certain goal. If the interface to the servers is the 
same across various nodes, the same tasks may be used 
with different resources . 


One of the agent function requirements is based on the 

peer-to-peer wireless connection for users (assumed to be 

44 Russell P. Lentini, Goutham P. Rao, Jon N. Thies, and Jennifer Kay; EMAA: 

An Extendable Mobile Agent Architecture, page 3, 1997 

Ibid 
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supervisory personnel at this time) on the flight deck described 
in chapter five. 

The previously mentioned Limited Objective Experiment 
conducted at the Naval Postgraduate School provided insight into 
a potential problem that could cause a detrimental effect to the 
wireless network. When a wireless device left the range of one 
antenna the applications on the wireless device would lock up. 
This was attributed to application robustness and resulted in 
excessive packet loss. A device required re-initialization of 
the application on the network once it was in range of another 
access point. To avoid this situation it will require the 
system to keep track of the devices that are currently on line. 
A dedicated design effort will be required to keep nodes 
connected so that the applications do not perform as an effect 
of packet loss. This will require devoted monitoring by an 
agent that will be both robust and mobile to monitor the signal 
strength and location of an individual user. This appears to be 
a logical parallel to cell phone technology that enables the 
phone to connect with the strongest transmitter in its 
environment. 
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VII. AIRCRAFT HANDLING DECISION SUPPORT REQUIREMENTS 


A. INTRODUCTION 

If the United States strategically plans to use military 
air power to overwhelm enemies with "Rapid Decisive Operations", 
advanced dynamic collaborative tools and intelligent agents will 
be of paramount importance. These tools and agents will be 
critical not only coordinating the individual flight deck in 
execution, but especially during the deliberate planning phase 
by coordinating several aircraft carriers in different areas of 
responsibility against the same threat or adversary. 

As the battle space becomes more dynamic, aircraft handlers 
will require timely and accurate information to process, analyze 
and decide, and then disseminate it quickly to subordinates on 
the flight deck to initiate a quick and decisive action. 



The ability to rapidly exchange information around the 
battle group and throughout the operational space will force the 
sequential, linear planning of the past to give way to 

46 White Paper for Joint Interactive Planning", United States Joint Forces 
Command, Joint Experimentation, Concept Division (J-92), 10 May 2000 
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simultaneous, interactive planning, which will greatly affect 
the tempo of execution. Simultaneous, parallel planning will 
shorten the "decide" component of the "observe-orient-decide- 
act" (OODA) cycle depicted in Figure 33 and will allow the Air 
Wing to gain significant leverage over the enemy. The result 
will be improved flight deck command and control and directed 
unity of effort . 

Information technology has already significantly changed 
the world in which military forces must operate. This 
technology, when combined with innovative organizational change 
and progressive business processes, can directly impact how Air 
Operations (Air Ops) plans and executes assigned missions. The 
Aircraft Handling Decision Support System (AHDSS) will combine 
existing functionality in both ADMACS and ISIS, yet maximize the 
utility of emergent technology deliberately over the life of the 
system. 

B. INTERACTIVE PLANNING AND COMMAND AND CONTROL 



Figure 34. Initial AHDSS Structure 

The AHDSS should be approached as flexible collection of 
interfacing tools. The initial AHDSS structure, as shown in 
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Figure 34, introduces Flight Deck Interactive Planning (FDIP) 
and Flight Deck Command and Control (FDC^) subsystems. 

This structure is used to help redefine and restructure 
existing business processes so available technology can be used 
to not only automate manual tasks, but also help the 
organization evolve to a new operational standard. This shift is 
critical because operational demands often exceed operational 
availability. This emphasizes the further requirement for 
planners and operators to process exponentially larger 
quantities of information rapidly and effectively. 

Planning and execution are the two actions that synchronize 
and sustain the application of air power. Therefore, the 
purpose of all the aircraft carrier functions, processes, and 
components are unified in a common effort. Air Ops must be able 
to rapidly exploit information from a wide range of traditional 
and non-traditional sources in order to integrate fully each 
asset that facilitates launching and recovering aircraft on 
aircraft carriers. 

This interactive planning is introduced and examined in the 
context of Decision Support Systems and then Air Wing Operations 
delineated in the context of Command and Control. 

Rapid Decisive Operations (RDO) is a concept to achieve 
rapid victory by attacking the coherence of an enemy's ability 
to fight. It is the synchronous application of the full range 
of our national capabilities in timely and direct effects-based 
operations. RDO on the carrier could employ asymmetric 
advantages in the knowledge, precision, and mobility of the air 
assets against an adversary's critical functions to create 
maximum shock and disruption, defeating the adversary's ability 
and will to fight. 
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C. FLIGHT DECK INTERACTIVE PLANNING (FDIP) 

Flight Deck Interactive Planning (FDIP) is defined as 
bringing together, through information technology, the right 
equipment, people and information at the right time for planning 
an operation. The result of the planning provides a shared 
awareness of the commander's intent maintained throughout the 
battle space. Having the right information at the right time 
will empower the Handler on the aircraft carrier to take control 
of the flight deck space and facilitate the battle group's 
ability to maintain the initiative. 

The FDIP intends to improve the speed of command and unity 
of effort. The FDIP will allow supporting staffs and other 
resources, both those on the ship and possibly those separated 
by geography, time and organizational boundaries, to allow all 
of the players to collaborate, develop, and coordinate unity of 
effort in planning and execution. By rapidly exchanging 
information of the commander's intent and plan throughout the 
battle space, FDIP could allow for simultaneous, parallel 
planning through force echelons of command, greatly improving 
the speed of command and reducing aircraft ordnance on-target 
response time. 

D. FDIP ELEMENTS 

The FDIP concept is made up of three primary elements 
including an Interactive Flight Deck Planning Group (FDPG), an 
adaptive, tailored planning process, and a dynamic, shared Air 
Plan space as depicted in Figure 35. 

The FDPG is a virtual collaboration environment that allows 
the co-location of applications, data, and users in a shared, 
persistent workspace. 
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Figure 35. FDIP Elements 


An adaptive, tailored planning process integrates the 
Interactive FDIP and the final Air Plan in a distributed 

environment that could replace deliberate or crisis-action 

planning by using alternative time and mission tailoring 
methods. 

A dynamic, shared Air Plan is the product of a continuous 
and developing planning process that evolves with the mission 
using information technology to provide effective presentation 
of recent (or real-time) information to ship's company, the Air 
Wing, the CVBG Staff, and other commanders. 

The strength of this approach is that the time 

traditionally needed for individual elements to realize a 
conflict in the execution of an air plan can be reduced or 

eliminated. 

The major decision support functions of the FDIP are: 

a. Collaboration 

b. Course of action (COA) development and analysis 

c. Course of action selection 
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Once the basic operations plan is decided, further 
refinements will encompass the following supporting plans to the 
last minute. Sub-categories are included to reflect greater 
detail. 

The Air Plan 

• Equipment 

• People 

• Supplies 

• Ordnance 

• Fixed and Rotary Wing Aircraft 

The flight deck support plan, as described in this paper, 
is comprised of six main support sections identified below. In 
addition, for best support, the Handler might attempt to 
maximize these within the principles of logistics, such as 
responsiveness, survivability, sustainability, attainability, 
simplicity, flexibility, and economy. These sections are: 

Flight Deck (V-1 Division) 

Catapult and Arresting Gear (V-2 Division) 

Hangar Deck (V-3 Division) 

Aviation Fuels (V-4) 

Squadron Maintenance 

Ship's Services 


E. FLIGHT DECK COMMAND AND CONTROL 

Flight Deck Command and Control (FDC^) is the part of the 
AHDSS system that will change as technology becomes available. 
This subsystem will coordinate the communication between the 
various nodes in the flight deck network. A node in the FDC^ 
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context will be any sensor, person, or object that feeds 
information into the FDIP. Further, the FDC^ will encompass the 

tools used by nodes on the flight deck or in the ship for 

heightened situational awareness. 

F. THE ROLE OF DECISION SUPPORT TOOLS 

The Decision Support System (DSS) tools could provide 

enormous assistance with providing the Air Boss, Handler, and 
other responsible actors with quick and relevant information to 
control the flight deck space. DSS tools would provide enormous 
support to help in deciding some planning factors such as: 

• Characteristics of the flight deck: 

• Climate, weather, EMCON condition; 

• Resources available; 

• Ship's and Aircraft Periodic Maintenance Schedule; 

• Expected interference with launching/recovery 
functions 

• Catapult readiness. 

• Tasks requiring special ordnance, supplies and 

equipment. 

G. DECISION SUPPORT SYSTEM ELEMENTS 

Decision Support System elements will include components of 
the DSS and also consider the decision styles of the traditional 
users of the system. These elements will be used as the initial 
criteria for evaluating both the effectiveness of intelligent 
agents and the various collaborative tools that might be used to 
support flight deck operations. If the ultimate system 
architecture is designed to adapt to the users, the decision 
styles may change, but the DSS components will not. The 
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intelligent agents will adapt, but this will be transparent to 
the user. 

The DSS components are shown in Table 2: 


Description 

Action or Issues 
related. 

Examples 

Area of usage 

Data 

Management 

System 

Retrieval, 
storage, and 
organization of 
the relevant data 

for a decision. 

Db, DBMS, Data 
repository, 
and data query 
facility 

Items, fuel 
capacities, 
ordnance, etc. 

Model 

System 

Performs 
retrieval, 
storage, and 
organizational 
activities for 
quantitative 
analysis 

Mb, MBMS, 

Model 

repository, 

model 

execution and 

model 

synthesis 

processor 

Time 

schedules, log 
requirements, 
locations, 
priority, etc 

Knowledge 

Engine 

Problem 

recognition and 
generation of 
interim or final 

solutions 

The "brains" 

of the outfit. 

Data and 

models come 
together 

Coordination 

of items and 

efforts 

User 

Interface 

Easy access and 
understanding for 
manipulation of 
the DSS 

Interface 

manipulation 

System 

interface 

DSS User 

Skill set, 
motivations, 
knowledge, 
domain, patterns 
of use, and role 
within the 

organization. 

Computer 
skills and 
flight deck 
information 

Section reps, 
planners 
and/or 
assistants 


Table 2. Decision Support System Components^'^ 


"Decision Support System to support Logistics for Joint Interactive 
Planning for Landing Force Operations", Mark Harrington, LT Andy Wiest, LCDR 
Harold Valentine, LCDR Tim Thate, June 2001 
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The Decision Styles of the various components involved in 


the decision are described in Table 3: 


Decision-Maker 

Style 

Main personality traits 

Air Wing 
Commander 

Directive 

Expects results, aggressive, 
communicative 

Air Boss 

Analytical 

/Directive 

Wants best answer. Innovative, 

Uses great care. Great data. 

Expects results. Intuitive, 
Communicative 

Handler 

Analytical 

/Directive 

Wants best answer. Innovative, 

Uses great care. Great data. 

Expects results. Intuitive, 
Communicative 

Flight Deck 
Officer 

Directive 

Expects results. Aggressive, 
Communicative 


Table 3. Decision Styles 


H. AIRCRAFT HANDLING INFLUENCE DIAGRAM 

The DSS for the flight deck is envisioned as a tool to more 
rapidly and dynamically allocate scarce resources in support of 
the mission. This view is intended to be high level in nature 
and specific quantifications have been avoided to give the "Big 
Picture". 

The Aircraft Handling Influence Diagram as shown in Figure 
36 begins the process of categorizing the information managed 
and decisions supported within the system. The Aircraft Handling 
DSS would be beneficial for further study and possible 
implementation to provide coordination between the requirements 
and the capabilities in greatest efficiency. 
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Figure 36. Aircraft Handling Influence Diagram 

I. SIMON'S MODEL FOR FLIGHT DECK PLANNING 

When considering how best to approach problem solving in a 
complex operational environment, a traditional theory is that 
people made rational decisions first by searching for all the 
different possibilities, evaluating those possibilities and then 
deciding which alternative best solved the problem or filled the 
need. 
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Herbert A. Simon, the 1978 Nobel Laureate in Economics did 
extensive research in how people make decisions. His bounded 
rationality model supposition was that people made limited 
rational decisions by searching some possibilities, evaluating 
one, and deciding upon the one sufficient enough to solve the 
problem or fill the need. 



Intelligence Design Choice 


• Environ m«nt 

• Ord«r of BattI* 

• Geography 

• Readiness 

• Force Symmetry/ 
Asymmetry 


■ Analyze various 
scenarios and 
path outcomes. 

• Involve all 
stakeholders 
and actors. 


* Decide on 
Optimal Course 
of Action 

• Establish 
Contingencies 


Model Validation < 

r Solution Testing ^ 



Reality 

Of 

Situation 



Resource 

Factors 

Environment 

Factors 


Implementation 


Success 


Outcome 


• Application of Assets 

• Asset Movement 

• Info Operations 


Failure 


Figure 37. Simon's Model Applied to Flight Deck Support 

When developing a decision support system, Simon's Model 
process becomes more realistic because it takes less time, 
yields an acceptable choice and cost significantly less in terms 
of time and resources. 

Simon's Model can also be readily used to illustrate the 
cyclical nature of Flight Deck Operations Support. As shown in 
Figure 37 above, the model quickly demonstrates the need for 
contingency plans and flexible structuring. In this way the 
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dynamics of the factors included in the Influence Diagram can be 
quickly considered and accounted for. 

The strength of this model is the process. All factors are 
listed. The problem is identified and a criterion for the 
solution set is developed. Alternatives are listed and evaluated 
so the decision maker can pick the best alternative. 

This process guarantees the best solution possible for the 
information given at a specific time. If something changes, the 
system can rapidly determine the next best alternative based on 
the change. According to Dr. Simon^^: 

Expert systems are generally constructed in close 
consultation with the people who are experts in the task 
domain. Using standard techniques of observation and 
interrogation, the heuristics that the human expert uses, 
implicitly and often unconsciously, to perform the task are 
gradually educed, made explicit, and incorporated in 
program structures. Although a great deal has been learned 
about how to do this, improving techniques for designing 
expert systems is an important current direction of 
research. It is especially important because expert 
systems, once built, cannot remain static but must be 
modifiable to incorporate new knowledge as it becomes 
available . 

Other issues to consider when evaluating a decision support 
model include: 

• Not all factors or parameters are listed 

• Wrong problem identified 

• Criteria is politically motivated 

• Incorrect evaluation of alternatives 

• Shallow implementation 

• Failure to recheck parameters 

• Lack of aggressive implementation 

48 Decision Making and Problem Solving, Herbert A. Simon et al., Research 
Briefings 1986: Report of the Research Briefing Panel on Decision Making and 
Problem Solving © 1986, National Academy of Sciences. 
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The strength of Simon's Model is that it is modifiable. The 
factors and parameters listed in Figure 37 are not inclusive nor 
take into consideration how the environment will change when new 
technology is adopted. 


J. ADAPTIVE PLANNING 

Organizational structures will impact the effectiveness of 
an organization, but the environment, the mission, and available 
personnel and material will directly influence each possible 
structure. The basic structures are illustrated in Figure 38. 



wheel Chain Circle Completely 

Network Network Network Connected 

Network 


Figure 38. Basic Communication Network Structures'^ 


The three basic Multi-participant Decision Maker (MDM) 
structures as suggested by C.W. Holsapple in 1991 are shown in 
Figure 39. George Marakas, author of "Decision Support Systems 
in the 21^^^ Century" defines MDM as: 

Multi-participant decision-making is an activity 
conducted by a collective entity composed of two or 
more individuals and characterized in terms of both 
the properties of the collective entity and of its 


Adapted from "Decision Support Systems in the 21^*^ Century", George M. 
Marakas, Prentice Hall, 1999 
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individual members. 



Multiple Nodes, 

Complete 

Interaction 


single Node, 

Complete 

Participation 



Team: Single Node, 

No Participant 
Interaction 


Figure 39. Basic MDM Structures'^ 


Initial direction for aircraft handling will come from the 
ACHO in Flight Deck Control, but the individual on the deck will 
often observe the changes in the environment that will affect 
the overall plan. Therefore, the most efficient organizational 

Ibid 

Ibid 
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structure for Flight Deck Planning Operations, in most cases 
will be the committee structure as illustrated in Figure 40. 




Figure 40. Flight Deck Planning Structure 


This structure begins at the highest level in the chain of 
command, but will be adjusted according to the leadership 
preferences of the individual actors or centers as appropriate. 

The actual interaction between the actors and centers will 
likely mirror the flow of information depicted in the influence 
diagram and Simon's model. 


K. LAYERED DECISION TABLES FOR FDIP 

The first step in defining parameters and criteria for 
evaluating collaborative tools for a complex organization is to 
identify a representative, but finite group of interdependent 
tasks and then map a logical flow of the associated information 
throughout the complex organization. 

This process is tedious, but valuable in understanding some 
of the unique and dynamic information requirements. As shown in 
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Figure 41, the initial flow of information for flight deck 
operations can be modeled and analyzed. 
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Figure 41. Layered Decision Tables 


Appropriate decision tables can be established and 
populated based on standard operating procedures and lessons 
learned in previous operations. Once the decision tables are 
populated, the collaborative tools should streamline the 
decision process by "volunteering" information and prompting 
appropriate responses from users throughout the organization. 
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L. 


THE HIGHER COORDINATION LAYER 


Conceptually, the Higher Coordination Layer (HCL), as shown 
in Figure 42, is made up of a broadly dispersed network of area 
and subject matter experts from Ship's Company, from individual 
Squadrons, or from the Air Wing. 


Feedback 



Figure 42. Higher Coordination Layer for FLIP 

The HCL is connected primarily through face-to-face 
interaction and email, and the group would combine for regularly 
scheduled training. The subject matter experts provide direct 
liaison between the Air Wing and their parent activities. 

In the HCL, a distributed social cognition (or heightened 
awareness of interdependency between organizational elements) 
must exist for the Air Wing to be successful and accomplish its 
goal. The overall goal in this layer is to integrate real-time 
situational awareness. All three entities must provide real¬ 
time collaborative operations and capability that will support 
planning, mission execution, monitoring, and rapid re-planning 
in the operational environment. Therefore, a strong foundation 
of unity of command and decisive real-time situational 
adaptation must exist. 
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M. THE FLIGHT DECK CONTROL LAYER 

The Flight Deck Control (FDC) layer defines the basic roles 
of all of the actors and their coordination roles and 
relationships as illustrated in Figure 43. 
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Figure 43. FDC Layer 


The Air Ops, Air Boss, and ACHO form a team with the goal 
of transforming an operational requirement into a prioritized 
logistical task. This is accomplished through mutual assurance 
relationships. 

The Air Operations Officer role is to ensure Flight Deck 
Control is responding to the operational commitments with the 
correct priority emphasis. The ACHO then inputs the task into 
the requirement node via the Flight Deck Control where it is 
input into a requirement database with the proper priority. 
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The relationship between the ACHO and Flight Deck Control 
is by direct supervision with the end goal of transforming the 
relationship into a mechanized bureaucracy. This mechanized 
bureaucracy is achieved through establishing and following 
Standard Operating Procedures (SOPs) and specific communication 
up and down the chain of command. Flight Deck Control delegates 
work to the appropriate service centers either sequentially or 
in parallel depending on the nature of the task at hand. Most 
tasks will require more than one center to contribute to an 
effective end. Table 4 below features examples of actors and 
associated sets of tasks. Therefore, even at this layer, there 
will be mutual adjustment or organizational compromise and what 
can best be characterized as a low level adhocracy. A low level 
Adhocracy combines elements of pure administration and simple 
bureaucracy. The outcome is a learned behavior to minimize 
delays in resolving issues between centers or actors. 


FDC ACTORS and 

SERVICE CENTERS 

TASKS 

Air Ops 

•Operational Point of Contact for 

Higher Layer 

• Coordinate Operational Requirements 

• Liaison with Air Boss 

• Liaison with ACHO to check status 

•Adjust operational timelines as 
supported by Flight Deck Control 

Air Boss 

• Operational Point of Contact for 

Higher Layer 

• Coordinate Operational Requirements 

• Liaison with Air Ops 

• Liaison with ACHO to check status 

•Adjust operational timelines as 
supported by Flight Deck Control 

Aircraft Handling 
Officer (ACHO) 

• Point of Contact for Higher 

Headquarters 
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• Coordinate Flight Deck Service Centers 
to support Operational Requirements 

• Liaison with Operations Officer 

• Directs the Logistics Center 

Flight Deck Support 
Centers 

• Flight Deck Officer 

• Catapult/Arresting 

Gear Officer 

• Hangar Deck Officer 

• Aviation Fuels 

Officer 

• Squadron 

Maintenance 

Officers 

• Ship's Services 

• Coordinates Support Tasks to meet 
Operational Requirements. 

• Centers coordinate with each other and 
with Flight Deck Control 

• ACHO can receive feedback from Flight 
Deck Control or from any of the 

Service Centers as appropriate 


Table 4. Actors and Tasks 


Flight Deck Control coordinates the service centers by 
direct supervision to meet the requisite variety of the task and 
its corresponding dynamic environment. The service centers work 
with one another in a mutual assurance-supporting role where 
they are forced to coordinate on their own terms. When 
conflicts arise, it will be de-conflicted by direct supervision 
from either Flight Deck Control or the ACHO. 

In the FDC layer a continuous process of CODA cycles exist. 
This process can be analyzed in terms of planning and execution. 
As missions occur the process follows a logical step of 
coordination through Flight Deck Control with all its 
components. This CODA process represents an organization 
exhibiting distributed social cognition as an emergent behavior. 


N. THE TASK LAYER 

The FDC task layer, as illustrated in Figure 44, will 


function to perform various tasks or solve problems. Therefore 
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the "Problem Focused" process will ultimately exist throughout 
all layers of the network. Also, as seen in all layers, 
multiple simultaneous processes will exist. Each process will 
address a specific task, but there will be circumstances where 
more than one process will compliment another to solve a 
specific problem. 



Figure 44. The Task Layer 

Intra and inter-coordination will be realized by the social 
cognition of the organization as a whole. Coordination is 
achieved through mutual adjustment and direct supervision (as 
described in the FDC Layer section above). 

This is the primary organizational structure in this 
dynamic scenario. Social cognition of the organization will be 
fully realized in the Decision Support System, but only after 
the decision tables are populated. 


O. FDC COLLABORATIVE TOOL AND AGENT TEST BED 
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The following tools or tool developments appear well suited 
for continued evaluation of Flight Deck Interactive Planning 
concept: 

• ORBIT (workspace environment) 

• Collaborative Virtual Workspace (CVW) 

• COMPASS Collaborative Package 

• Info Work Space (IWS) (workspace environment) 

• ODYSSEY (workspace environment) 

• GENOA Segments (web tools) 

• Adaptive Course of Action (ACOA) tools 

• Advanced Concept Technology Demonstration (ACTD) tools 

• MSIAC tool package 

• Course of Action Display and Evaluation Tool (CADET) 

• EOX Genetic Algorithm 

The Naval Postgraduate School (NPS) has a regular student 
base of over twelve hundred military officers. The student body 
includes international officers from both NATO and coalition 
countries. 

Erom an operational perspective, there is a wealth of 
knowledge and experience at NPS that would facilitate meaningful 
evaluation of collaborative tools and intelligent agents to 
support Plight Deck Interactive Planning (EDIP) and Plight Deck 
Command and Control (EDC^) initiatives. 

P. AGENT COMPONENTS FOR FLIGHT DECK CONTROL 

The Intelligent Agent (lA) architecture should be expanded 
to facilitate more effective action/reaction times to changing 
circumstances impacting an operational mission. 


124 




The goal is to keep the decision makers informed of "real 
time" critical information that would directly impact the 
mission. Looking at the Observation, Orientation, Decision, and 
Action (OODA) loop model, effective planning and timely updates 
would reduce "observe" and "orient" times and allow the war 
fighter to decide and act faster than the adversary. The 
quicker OODA loop would ultimately be more responsive and keep 
the enemy off balance or "paralyze" him to the point of being 
ineffective. 

For example, once the primary planning cell assessed a 
crisis and developed the overall plan, several logical Courses 
of Action (COA) could be identified. 

Intelligent Agents could facilitate extensive direction, 
collaboration, and coordination before and throughout an entire 
mission. Additionally, they could translate a proposed COA into 
a statement of requirements and provide tailored packages 
depending on operational requirements and the operational 
environment. 

Scenario driven solutions would enable projected aircraft 
spotting and re-spotting requirements. This leveraged knowledge 
would allow Flight Deck support personnel to make real-time 
analysis of present and future necessities. 

Central to all other capabilities is the ability to 
collaboratively translate plans of aircraft movement into plans 
of support and then to responsively assess the strengths and 
weaknesses of the resulting plans. This translation and 
assessment capability contributes not only to reduce operational 
risk, but also to preserve operational options for the Air Wing. 
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VII. RECOMMENDATIONS 


A. INTRODUCTION 

Our recommendations are based on the research we have 
conducted and our experiences while interacting with various 
agencies and companies during our data collection. One of the 
requested outputs of this thesis is a recommendation on how, 
from a business perspective, this project would proceed, and 
which entities (companies, DOD activities, etc.) would logical 
continue this work. 

We have attempted to display the recommendations as 
requirements for a fielded system. As such, many of the 
requirements could be considered independently or deleted from 
the system without completely disabling the system or reducing 
the value added it would have for the fleet. However, some of 
these requirements will have to be integrated for the system to 
function correctly. Accordingly, we will annotate items of 
importance as "system critical" in an attempt to safeguard those 
items from future removal or uninformed modification. 

Depending on the time it takes to endorse and incorporate 
our findings into a true requirements document and then field 
the system, newer technology will likely be commercially 
available. Therefore, it is our opinion that the system be 
designed with change in mind. The system should be designed to 
rapidly shift to faster hardware or operating systems to enhance 
system performance. 

B. REASONS FOR ADOPTING CHANGE 

The current system as described in previous chapters is 
effective, but is not at all efficient. The most compelling 
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reason for this organization to embrace change would be to 
increase the efficiency of updating and disseminating 
operational information used by the various departments that 
require it. This vision compliments the publicized operational 
goals of the newest class of U.S. aircraft carriers. 
Specifically, CVNX charter requires a 20% greater sortie rate 
than the current Nimitz Class carrier with the same number of 
personnel, aircraft, and deck space. 

Our contention is that the only way this goal can be 
realized is to leverage every technological advantage possible. 

C. RECOMMENDED CHANGES 

A "system of systems" requires a streamlined design that 
will integrate all the latest software technology and database 
advancements. The current system is a case study in legacy 
applications that are all unique solutions for individual 
problems. Apparently little thought was given to data 
visibility to other applications when many of these systems were 
developed; hence interoperability was not a significant 
consideration when these "stovepipe" systems were designed. 
Further, redesigning these legacy systems will be time consuming 
and costly. 

As discussed in the Agents chapter in this thesis, it would 
be possible to create an interface layer that would 
theoretically facilitate legacy system interoperability. 
Intelligent agents could be used to create the linkage between 
the disparate systems. However, this approach has significant 
flaws. First, many of the systems that would be linked by an 
agent layer are funded by different sources and are essentially 
treated as stand-alone systems. Each system has a life of its 
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own and it cannot be expected that each program will routinely 
consider other interfacing systems. If a system or program were 
discontinued, all secondary users would be impacted. 
Functionality and information would be lost until a "workaround" 
was determined or until a new system was plugged in to replace 
the previous system. 

Furthermore, designing intelligent agents that would permit 
interoperability would require all of the individual systems 
interfaced to remain stable. If one of those systems were 
upgraded, then the unifying agent's layer would have to be 
tested and possibly reprogrammed to sustain functionality and 
connectivity. It is clear that the agents themselves will 
inherently be robust, but any system modifications will 
undoubtedly require a planned re-certification to verify that 
changes had no adverse effect on other mission critical systems. 

There is also the issue of ownership. Who will be 
responsible for the agent management and evaluation? Individual 
Program Managers from the various systems will be reluctant to 
adopt these costs, as the agent layer is not part of their 
system. It would initially be considered beyond the scope of 
their project to evaluate the effect of changes in their 
software or hardware on other systems. 

Yet another issue is a question of performance and the 
ability of these legacy systems to shift to more efficient 
technology. For example, 2 GHz chips and GIGABIT Ethernet are 
commercially available. How many years will pass before this 
technology is integrated into military systems? 

The ADMACS system is running on a proprietary Hewlett 
Packard (HP) system that has not been manufactured in over five 
years. HP no longer supports it. NAVAIR is apparently 
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compensating by acquiring legacy HP Systems from other 
governmental entities or from Defense and Reutilization & 
Marketing Service as components are discarded. 

Engineers at Northrop Grumman's Newport News Ship Yard 
suggest that the data management system be overhauled first. We 
agree. Deliberately establishing a foundation database capable 
of handling a myriad of system and sensor information is 
logical. Any use of automated sensors for aircraft position and 
orientation information is useless without a system robust 
enough to appropriately and efficiently handle the large volume 
of data. 

In theory, the ADMACS system has this architecture. It is 
our observation, however, that ADMACS is largely dependant on 
fixed hardware and legacy systems run on proprietary and 
inflexible software. The hardware is not "state of the art", 
and therefore, the potential performance possible with newer 


technology 

will 

not be 

easily realized. 

This 

could 

have 

significant 

ramifications 

when considering 

the 

addition 

of 

multiple complex 

integrated sensors. It is 

our 

opinion 

that 


NAVAIR revisit current ADMACS efforts and purposefully redesign 
the entire system. 

Initially, we would recommend the two primary Type 
Commanders (TYCOMS) (COMNAVAIRPAC and COMNAVAIRLANT) facilitate 
comprehensive requirements modeling for aircraft handling to 
definitively identify all of the functional requirements that a 
ship-wide system would have. Again, many of these data 
requirements are listed in the ADMACS Integration List (Appendix 
A) . The drawback to this initial list is that it comes directly 
from the ADMACS program. 
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This approach enforces the premise that the "Fleet" 
determines system requirements. 

D. IDEAL SYSTEM ATTRIBUTES 

One Database - The ideal system will have a single database 
with segregated data fields so that specific users will have the 
ability to modify only the fields that they have cognizance 
over. 

For example, the squadron could only change information 
regarding a squadrons' aircraft, such as configuration and "up" 
or "down" status. Numerous users including V-4 or the squadron 
who owns the aircraft, however, could modify an aircraft's fuel 
status. In this case, the squadron could input the initial fuel 
quantity, but the Fuels Division could update the refueling (or 
de-fueling) status. 

Develop Accurate Requirements - The ADMACS team and others, 
such as Northrop-Grumman have utilized process modeling to 
assist in developing the system requirements. This is desirable 
since there are many variables with multiple dependencies in the 
daily operation of the flight deck. It is imperative that the 
modeling is accurate in all of the steps that are involved in 
regular and special evolutions. 

NAVAIR and a third party (one independent of the 
acquisition process and one without to prospective contractors) 
will be crucial for the modeling flight deck operations. 

The Modeling, Virtual Environments and Simulation (MOVES) 
Institute at the Naval Postgraduate School (NPS) is a logical 
candidate for this work. Note that the NPS is able to compete 
for SBIR contract work from other Navy (and other government) 
activities. 
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Establish Data Ownership - Once the processes are 
accurately modeled, all of the required data fields for the 
database can be established. Specific ownership can then be 
applied to each data field. It stands to reason that there will 
be some debate over who should have ownership of some fields, 
but the TYCOMs will be the logical players to mediate such 
discussions. 

Suggest Courses of Action - Input from interviewees made it 
abundantly clear that a system that proposes solutions and 
alternatives is desirable - one that mandates an action is not 
acceptable. We understand and agree with these assertions. 
This system is envisioned to assist operators, not replace them. 
We have a deep appreciation for the abilities of the Handlers 
who currently do their jobs with a minimal amount of technology. 
But, we believe that a new system will aid Handlers by giving 
them more accurate and timely information allowing the operators 
to make the best decisions. 

The added benefits that we envision are that every other 
air operations activity aboard the ship will be able to see what 
is going on, without having to contact FDC or the ACHO. An 
additional benefit is that the system can be used to train other 
personnel to be handlers. Both the Handler and the trainee can 
"what-if" the system to death, making full use of a built in 
"scenario" capability. The ramifications of this capability 
cannot be overemphasized. For instance, if a part is on order 
for one of the catapults, the Handler could run a scenario 
illustrating how not having that catapult will effects 
operations. The impact of that part not getting to the ship on 
time can be easily documented using a cause and effect approach. 
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This scenario can also be used to show the cumulative effect on 
the next days Air Plan. 

Flexible Interface Capability - Other input stressed the 
need to allow the users to customize the interface to give them 
as much or as little data as they require for their job or for 


their leadership 

style. It 

is reasonable 

to assume 

that 

the 

display options 

could be 

programmed 

for 

this 

type 

of 

functionality. Eor example. 

the Euels guys 

have 

less 

need 

for 


details about ordnance requirements for a particular aircraft 
unless the ordnance impacts if they can fuel or de-fuel an 
aircraft. Likewise, the Handler may want to see just the 
"comers" or just the aircraft that are up for the next launch. 
This level of customization should be considered a priority to 
the system design. 

Accuracy and Latency - The current EATS is accurate to 
within a few feet. This may prove to be accurate enough in the 
short-term as it is certainly more accurate than the current 
manual system. It stands to reason, however, that more accuracy 
will provide more efficiency. If the handler is able to 
visualize the aircraft stacked in the Bow Rows to within an 
inch, he may be able to park an additional aircraft on the bow 
that he might have attempted otherwise. The sensors should be 
able to deliver accuracy to within 1 to 2 inches on the 
approximate 100 meter by 300-meter flight deck. 

Obviously, the system should have as little latency as 
possible. Again, the experience with EATS is that refresh rates 
much less than that used for motion pictures are sufficient. 
This assumes targets as large as aircraft and speeds less than 
15 MPH. If future capabilities of the system require tracking 
of humans or even human hand motions, refresh rates should be 
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increased. Ideally, the display should be able to display the 
movement of aircraft as a smooth, non-hesitating motion. This 
flow will be perceived as a measure of accuracy. For example, 
if the aircraft is displayed in a jerky way, the system will be 
perceived as less accurate. 

Effective use of Intelligent Agents - Latency and accuracy 
both are dependant on the sensors used. The number of and 
integration of sensors will play a large factor on the bandwidth 
and processing power required to accurately display the objects. 
Obviously, if the number of sensors increases, sensor 
integration will be a bigger challenge. 

Sensor integration is an appropriate place to use Agents. 
Discussions with Lockheed's ATL left us with the impression that 
they could address this sensor integration problem by 
appropriately coding agents to correlate track information seen 
by multiple sensors such that the display would reveal a more 
accurate and complete depiction of the situation on the deck 
even when some of the sensors might be obscured. Additionally, 
agents would be able to predict motion when a sensor is 
temporarily "blinded" by an obstruction. Agents would be able 
to alert the human operator if a track lost its identification 
information. The operator would be prompted to re-identify the 
target for the system. 

System Reliability - Due to the interdependency built into 
a system such as this, too many mission critical processes will 
be affected in the event of an unscheduled system failure. 
Adequate system redundancy and critical path analysis will be 
imperative to ensure that the system is either up or functional 
even in a degraded state while technicians correct whatever 
failure occurred. 
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The level of reliability can be scientifically established 
and appropriate hardware and software redundancy designed into 
the system. As shown in Figure 45, reliability can be defined 
in minutes of system downtime during a specific period. 




Figure 45. Down Time 


In general, if the system required 99.99% reliability, the 
system would be unavailable a total of 86.4 seconds during that 
reporting period. Considering safety will be directly impacted 
by system down time, reliability should be increased 
appropriately. 

The current emphasis in Department of Defense and in 
particular Department of the Navy is the use of Microsoft based 
products in support of Information Technology for the 21st 
Century (lT-21) and Navy Marine Corps Internet (NMCI) 


initiatives. As a result of this emphasis, many of the enlisted 
technicians are trained specifically as Microsoft technicians in 
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order to be able to address the issues that they will most 
likely encounter. 

Our intention is not to dictate a particular software 
package for use as the operating system, the database, or any of 
the application interfaces. It will be incumbent upon the 
actual systems designers and the Project Manager to make a 
considered choice as to which software will provide the balance 
between reliability and serviceability. It has been our 
experience that proprietary software or even non-Navy standard 
software can be problematic when used in an environment, such as 
a ship at sea, which does not readily allow service calls from 
the vendor. The danger of using a Linux or UNIX operating 
system is the added requirement for specially trained 
technicians to service the system when the need arises. It is 
not reasonable to assume that this system, if written on non- 
Navy standard software, would be large enough for the Radioman 
(Data Processing) "A" school to shift its curriculum to focus 
more on non-Microsoft products. 

A strategy can also be determined to anticipate system 
recovery upon a failure. For example, data could be cached in 
the functional work center that "owns" the data. 

In order to allow for graceful degradation and systematic 
recovery of data after a system failure, the data "owner" could 
have local data storage of the data fields under his cognizance. 
These local stores could then regularly synchronize with the 
main database when connectivity is reestablished. This provides 
for continued local functioning even when partial or entire 
system disruption occurs, and it allows for the system to 
reestablish the most current information to all users, as the 
different functional areas come back on-line. 
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Since many users and applications depend on data from other 
functional work centers, their data will also need to be cached 
locally in the event of a system malfunction or shipboard 
casualty. The only practical difference between the two 
situations stated above is that the second type of user will not 
be able to update or change the data that he does not usually 
have the ability to change. 

E. POSSIBLE PARTICIPANTS 

The current ADMACS engineers and program managers from 
Lakehurst should be involved in this effort. Our work on this 
thesis has allowed us to interface with numerous software and 
hardware vendors, as well as DoD contractors who have a long 
history of doing business with the DoD and in particular with 
the Navy. 

We do not necessarily believe that Lakehurst should be the 
lead in this new system development. There is a developmental 
history that exists with the current system, ADMACS, and 
considering the significant investment in that program, any 
lessons learned should be used. But it is evident that system 
design should be approached from outside the established 
organization to avoid the pressure to maintain the status quo.^^ 

Northrop-Grumman has developed and presented an impressive 
prototype. Considering past performance in other successful 
defense project, we feel that they are a logical contractor to 
approach in developing this system. More importantly, they are 
the prime contractor on the CVNX project. 


We were informed that NAVAIR has spent over $74 Million on the current 
system. It is not clear if this includes pre-payment to establish the system 
on all current Carriers, but to date it is not deployed on all. 
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While it is obvious that this system will primarily serve 
the Air Wing and the Air Departments aboard a carrier, this 
system is still a shipboard system. It should be designed and 
developed as an integral part of the next-generation carrier. 
This again makes the Northrop-Grumman recommendation a logical 
one. 

Informal discussions with other companies have made it 
clear that there is both industry knowledge and industry 
interest in a project like this. 

One of the most recent responses we received from Raytheon^^ 
describes, in no uncertain terms, that they can provide the 

sensor portion of this system with current technology that they 
have developed for other DOD programs. This could be 

particularly beneficial in keeping the costs down by reusing DoD 
assets. 

Pulnix Corporation, Develosoft, and the other companies 
mentioned in this thesis should also be considered. 

F. REVIEW OF EXISTING AND DEVELOPMENTAL SYSTEMS 

The proposed ADMACS Block II Upgrade stated that system 

integrators would need to have a firm grasp of (a) what all of 

integrated systems contained, and (b) what ADMACS needed from 

each of those systems. 

It is apparent that there is more than one way to 
effectively integrate systems, but we believe the first goal of 
the system integrator will be to avoid trying to maintain all 
the legacy systems (the status quo) . The issues will always be 

E-mailed proposal from Joseph R. Wood, Senior Principal Electronics 
Engineer, Raytheon Company, Projects Department, Electronic Systems 
Laboratory, P.O. Box 1201, Tewksbury, MA. 01876-0901 
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complex, but the biggest barrier to successful change in this 
system will not be technology, but organizational culture. 

With this difficulty aside, we were able to ascertain that 
there are hundreds of data fields in fifteen or more systems 
that are identified for the ADMACS to use as data sources. 

Appendix A details various input datum from the different 
systems. The appendix is primarily organizational and does not 
detail the specific data or data format to and from other 
systems. The output from an individual input system is less 
important at this point since, in our opinion, the correct thing 
to do is collect all of the data into one powerful database that 
will be able to "feed" any existing or subsequent system 
developed for future applications. In fact, we believe that 
once this database is developed, many of the legacy systems 
would quickly become obsolete. 
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VIII. CONCLUSIONS 


The ability to make effective decisions with limited 
resources has never been more important. Approaching the Digital 
Ouija Board from integrated system architecture as shown in 
Figure 46 illustrates how complex it can be to provide 
meaningful information to the war fighter. The direct benefit of 
this visualization is that the elements can be addressed and 
appropriate technology adopted and integrated. 
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Computer Equipment graphics adapted from www.sensorsapplications.com, 
June 20, 2002 
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Emerging collaborative tools, intelligent agents, and 
"cutting edge" technology can be effectively and proactively 
integrated into all facets of flight deck planning and mission 
execution. 

If the United States military strategically plans to 
continue to overwhelm enemies, advanced and flexible 
collaborative tools and intelligent agents will be of paramount 
importance. 

Accurate "requirements modeling" will be necessary for 
subsequent research efforts to effectively identify the 
collaborative tools and intelligent agents to support "Rapid 
Decisive Operations" in projecting air power. 

The current Aviation Data Management and Control System 
(ADMACS, described in Chapter III) system software is running on 
proprietary Hewlett Packard hardware that is no longer 
manufactured. Since a computer's useful life is approximately 
three years, the system architecture should plan regular 
upgrades and embrace open standards that will make future 
interoperability less of a problem. 

The sensor system that feeds the data management system 
should be platform independent. In a modular sense, today's 
sensor will be replaced by something more effective tomorrow. 
The change should be transparent to the user because system 
functionality would be consistent. The CoABS multi-agent 
middleware recently developed by DARPA serves that goal. 

The Peer-to-Peer (P2P) Limited Objective Experiment 
detailed in chapter four demonstrated how network management 
tools could be used to view a complex organization and monitor 
the flow of information. 
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The same tools should be used to design the information 


system that will support the Ouija board. This system can be 
virtually assembled and analyzed through simulations, then 
modified as necessary. More importantly, as the actual system 
is used in the operational environment, it can be monitored and 
managed as elements or nodes are added or removed from the 
network. 

The ability to capture, archive, and analyze live network 
traffic will provide system engineer's and managers the 
documentation to justify meaningful improvements to subsequent 
versions of the system. 

In view of recent asynchronous terrorist attacks on the 
United States, the ability to rapidly identify a mission, 
identify required personnel and critical material will make the 
difference between ultimate mission success or mission failure. 

The primary benefits of passive video capture, real time 
three-dimensional rendering and P2P communications on the flight 
deck or hangar bay is enhanced operational awareness. The 
infrastructure that facilitates this awareness will be the 
foundation for future advances in operational effectiveness. 
Approaching flight deck communication and operational command 
and control tasks from a network management perspective will 
allow the organization to use a broader range of tools to 
deliver operational success. 

Collaborative tools and environments as well as dynamic 
intelligent agents will be integral to successfully moving 
against adversaries as they are revealed regardless of where 
they might be in the world. 
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APPENDIX A: ADMACS INTEGRATION LIST 


WORK CENTER (USER) 


IDENTIFICATION 

LOCATION 
(CVN68 class) 

SYSTEM / 
Application 

ALL 

ALL 



Air Operations 

03-170-0 

ISIS 

Air Operations 

03-170-0 

ISIS 

Air Operations 

03-170-0 

ISIS 

Air Operations 

03-170-0 

ISIS 

Air Operations 

03-170-0 

ISIS 

Air Operations 

03-170-0 

ISIS 

Air Operations 

03-170-0 

ISIS 

Air Operations 

03-170-0 

ISIS 

Air Operations 

03-170-0 

ISIS 

Air Operations 

03-170-0 

ISIS 

Air Operations 

03-170-0 

ISIS 

Air Operations 

03-170-0 

ISIS 

Air Operations 

03-170-0 

ISIS 

Air Operations 

03-170-0 

ISIS 

Air Operations 

03-170-0 

ISIS 

Air Operations 

03-170-0 

ISIS 

Air Operations 

03-170-0 

ISIS 

Air Operations 

03-170-0 

ISIS 

Air Operations 

03-170-0 

ISIS 

Air Operations 

03-170-0 

ISIS 

Air Operations 

03-170-0 

MQRIAH Wind 

AOCC 

1-74-2-Q 

AWIMS 

AOCC 

1-74-2-Q 

AWIMS 

AOCC 

1-74-2-Q 

AWIMS 

AOCC 

1-74-2-Q 

AWIMS 

AOCC 

1-74-2-Q 

AWIMS 

AOCC 

1-74-2-Q 

AWIMS 

AOCC 

1-74-2-Q 

AWIMS 

AOCC 

1-74-2-Q 

ISIS 

AOCC 

1-74-2-Q 

ISIS 

Arresting Gear Officer 

04-230-S 

ALRCS 

Arresting Gear Officer 

04-230-S 

ALRCS 

Arresting Gear Officer 

04-230-S 

ISIS 

AUXCON 

08-159-0-C 

MQRIAH Wind 

BALLOON INFLATION RM 

01-255-3-Q 

ISIS 

BALLOON INFLATION RM 

01-255-3-Q 

MQRIAH Wind 

BOMB ASSY MAG 

6-84-0-M 

AWIMS 

BOMB ASSY MAG 

5-129-0-M 

AWIMS 

CAG Ops 

03-138-2 

AWIMS 

CAG Ops 

03-138-2 

AWIMS 



LABEL 

(Data / Data Blocks) 

System Status 

Time _ 

Air Plan 

Airborne Tanker Status 
Alert Aircraft Status 
ASW Datum 
Bingo Fuels 
Charts / Maps 
Communication Plan 
Current Ship's Position 
Current Ship's Weather 
Daily Call Signs 
Divert Aircraft Status 
Divert Field Info 
Equip (Radar) Status 
Event Information 
Helo Status 

Pilot Qualifications/Grades 
Plane Guard Ship 
Recovery Video 
Ship's PIM 

Tanker/Helo Status (Deck) 
Wind Speed & Direction 
Bomb Farm Log 
Magazine Arrangement 
Master Magazine Temp Log 
Mission Load List 
On Load & Flow Sheet 
Status Board 
Weapons Inventory/Info 
Air Plan 

Event Information 
Aircraft Bulletins 
ALRE Status / Information 
Event Information 
Wind Speed & Direction 
Event Information 
Wind Speed & Direction 
Status Board 

Status Board _ 

Mission Load List 
Weapons Board_ 

































WORK CENTER (USER) 

IDENTIFICATION 

LOCATION 
(CVN68 class) 

CAG Ops 

03-138-2 

CAG Ops 

03-138-2 

CAG Ops 

03-138-2 

CAG Ops 

03-138-2 

CAG Ops 

03-138-2 

CAG Ops 

03-138-2 

CAG Ops 

03-138-2 

CAG Ops 

03-138-2 

CAG Ops 

03-138-2 

CAG Ops 

03-138-2 

CAG Ops 

03-138-2 

CAG Ops 

03-138-2 

CAG Ops 

03-138-2 

CAG Ops 

03-138-2 

CAG Ops 

03-138-2 

CATCC 

03-170-1 

CATCC 

03-170-1 

CATCC 

03-170-1 

CATCC 

03-170-1 

CATCC 

03-170-1 

CATCC 

03-170-1 

CATCC 

03-170-1 

CATCC 

03-170-1 

CATCC 

03-170-1 

CATCC 

03-170-1 

CATCC 

03-170-1 

CATCC 

03-170-1 

CATCC 

03-170-1 

CATCC 

03-170-1 

CATCC 

03-170-1 

CATCC 

03-170-1 

CATCC 

03-170-1 

CATCC 

03-170-1 

CATCC 

03-170-1 

CATCC 

03-170-1 

CATCC 

03-170-1 -Q 

CATOFF1 EMERGENCY 

CONTROL STATION 

04-149-2(P) 

CATOFF1 EMERGENCY 

CONTROL STATION 

04-149-2(P) 

CATOFF2 EMERGENCY 

CONTROL STA 

04-74-1 (S) 

CATOFF2 EMERGENCY 

CONTROL STA 

04-74-1 (S) 

CC CAT1 

CC CAT1 

03-79-9-Q 


SYSTEM / 
Application 


ISIS 

ISIS 

ISIS 

ISIS 

ISIS 

ISIS 

ISIS 

ISIS 

ISIS 

ISIS 

ISIS 

ISIS 

ISIS 

ISIS 

ISIS 


ISIS 

ISIS 

ISIS 

ISIS 

ISIS 

ISIS 

ISIS 

ISIS 

ISIS 

ISIS 

ISIS 

ISIS 

ISIS 

ISIS 

ISIS 

ISIS 

ISIS 

ISIS 

ISIS 

SPN-46 
MORIAH Wind 


ALRCS 
MORIAH Wind 


ALRCS 
MORIAH Wind 


ALRCS 
MORIAH Wind 


LABEL 

_(Data / Data Blocks) 


Airborne tanker status 
Aircraft Status (Deck) 
Aircraft Weight 
Alert Aircraft Status 
Bingo Fuels 
Charts / Maps 
Communication Plan 
Current Ship's Weather 
Divert Aircraft Status 
Divert Field Information 
Event Information 
Event Information 
Pilot Oualifications/Grades 
Recovery Video 
Ship's PIM 


Air Plan 

Airborne tanker status 
Alert Aircraft Status 
Bingo Fuels 
Charts / Maps 
Communication Plan 
Current Ship's position 
Current Ship's Weather 
Daily Call Signs 
Divert Aircraft Status 
Divert Field Info 
Equip (Radar) status 
Event Information 
Event Information 
Pilot Qualifications/Grades 
Recovery Video 
Ship's PIM 
SPN-46 info 

Tanker/Helo Status (Deck) 
SPN-46 info 

Wind Speed & Direction 


Launch Info 

Wind Speed & Direction, 
Crosswind/Headwind 


Launch Info 

Wind Speed & Direction, 
Crosswind/Headwind 


Launch Info 

Wind Speed & Direction 
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WORK CENTER (USER) 


IDENTIFICATION 

LOCATION 
(CVN68 class) 

SYSTEM / 
Application 

LABEL 

(Data / Data Blocks) 

CC CAT2 

ALRCS 

Launch Info 

CC CAT2 

OS-69-4-0 

MORIAH Wind 

Wind Speed & Direction 

CC CATS 


ALRCS 

Launch Info 

CC CATS 

OS-148-8-0 

MORIAH Wind 

Wind Speed & Direction 

CC CAT4 


ALRCS 

Launch Info 

CC CAT4 

OS-161-2-0 

MORIAH Wind 

Wind Speed & Direction 

CDC 

OS-156-0 

ISIS 

Air Plan 

CDC 

OS-156-0 

ISIS 

Airborne tanker status 

CDC 

OS-156-0 

ISIS 

Aircraft Status (Deck) 

CDC 

OS-156-0 

ISIS 

Alert Aircraft Status 

CDC 

OS-156-0 

ISIS 

ALRE Status 

CDC 

OS-156-0 

ISIS 

ASW Datum 

CDC 

OS-156-0 

ISIS 

Bingo Fuels 

CDC 

OS-156-0 

ISIS 

Charts / Maps 

CDC 

OS-156-0 

ISIS 

Communication Plan 

CDC 

OS-156-0 

ISIS 

Current Ship's position 

CDC 

OS-156-0 

ISIS 

Current Ship's Weather 

CDC 

OS-156-0 

ISIS 

Daily Call Signs 

CDC 

OS-156-0 

ISIS 

Divert Field Info 

CDC 

OS-156-0 

ISIS 

Equip (radar) status 

CDC 

OS-156-0 

ISIS 

Event Information 

CDC 

OS-156-0 

ISIS 

Event Information 

CDC 

OS-156-0 

ISIS 

Helo Status 

CDC 

OS-156-0 

ISIS 

Plane Guard Ship 

CDC 

OS-156-0 

ISIS 

Recovery Video 

CDC 

OS-156-0 

ISIS 

Ship's PIM 

CDC 

OS-160-0 

MORIAH Wind 

Wind Speed & Direction 

CDC Electric Warfare Area 

OS-165-1 

MORIAH Wind 

Wind Speed & Direction 

Damage Control ? 

AWIMS 

Weight Report 

FDC 

04-160-1 

AWIMS 

Bomb Farm Log 

FDC 

04-160-1 

AWIMS 

On Load & Flow Sheet 

FDC 

04-160-1 

AWIMS 

Weapons Location on Flight 
Deck/Hangar Deck 

FDC 

04-160-1 

ISIS 

Air Plan 

FDC 

04-160-1 

ISIS 

Airborne Tanker Status 

FDC 

04-160-1 

ISIS 

Aircraft Bulletin 

FDC 

04-160-1 

ISIS 

Aircraft Status (Deck) 

FDC 

04-160-1 

ISIS 

Aircraft Weight 

FDC 

04-160-1 

ISIS 

Alert Aircraft Status 

FDC 

04-160-1 

ISIS 

Event Information 

FDC 

04-160-1 

ISIS 

Event Information 

FDC 

04-160-1 

ISIS 

Recovery Video 

FDC 

04-160-1 

ISIS 

Weapons Information 

FDC 

04-160-1 

ISIS 

Wind Information 

FDC 

04-160-1 

ISIS / ALRCS 

ALRE Status 

FLAG BRIDGE/PLOT 

07-159-1 -C 

ISIS 

Event Information 
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WORK CENTER (USER) 

IDENTIFICATION 

LOCATION 
(CVN68 class) 

FLAG BRIDGE/PLOT 

07-159-1 -C 

FOSAMS/ROLMS 

02-84-P 

G1 WORKCENTER 

1-133-4-A 

G1 WORKCENTER 

1-133-4-A 

G1 WORKCENTER 

1-133-4-A 

G1 WORKCENTER 

1-133-4-A 

G1 WORKCENTER 

1-133-4-A 

G2 Division Work Center 

3-82-2-0 

G2 Division Work Center 

3-82-2-0 

G2 Division Work Center 

3-82-2-0 

G2 Division Work Center 

3-82-2-0 

G2 Division Work Center 

3-82-2-0 

G-3 Division Office (FWD) 

2-54-4-0 

G-3 Division Office (FWD) 

2-54-4-0 

G-3 Division Office (FWD) 

2-54-4-0 

G-3 Division Office (FWD) 

2-54-4-0 

G-3 Division Office (FWD) 

2-54-4-0 

G-3 Division Office (FWD) 

2-54-4-0 

G-3 Division Office (FWD) 

2-54-4-0 

G-3 Division Office (AFT) 

3-143-3-0 

G-3 Division Office (AFT) 

3-143-3-0 

G4 Division Work Center 

02-170-1 -L 

G4 Division Work Center 

02-170-1 -L 

G-5 Inventory Accounting 

02-64-4-0 

G-5 Inventory Accounting 

02-64-4-0 

G-5 Inventory Accounting 

02-64-4-0 

HDC 

1-94-S 

HDC 

1-94-S 

HDC 

1-94-S 

HDC 

1-94-S 

HDC 

1-94-S 

HDC 

1-94-S 

HDC 

1-94-S 

HDC 

1-94-S 

HDC 

1-94-S 

HDC 

1-94-S 

HDC 

1-94-S 

HDC 

1-94-S 

HDC 

1-94-S 

ICCS 1&2 

03-70-1-0 

ICCS 1&2 

03-70-1-0 

ICCS 1&2 

03-138-2 

ICCS 1&2 

03-70-1-0 

ICCS 1&2 

03-70-1-0 


SYSTEM / 
Application 


MORIAH Wind 


AWIMS 


AWIMS 

AWIMS 

AWIMS 

AWIMS 

ISIS 


AWIMS 

AWIMS 

AWIMS 

AWIMS 

ISIS 


AWIMS 

AWIMS 

AWIMS 

AWIMS 

AWIMS 

AWIMS 

ISIS 


AWIMS 

ISIS 


AWIMS 

ISIS 


AWIMS 

AWIMS 

ISIS 


AWIMS 

AWIMS 

AWIMS 

ISIS 

ISIS 

ISIS 

ISIS 

ISIS 

ISIS 

ISIS 

ISIS 

ISIS 

ISIS / ALRCS 


ALRCS 

ALRCS 

ISIS 

ISIS 

MORIAH Wind 


LABEL 

_(Data / Data Blocks) 


Wind Speed & Direction 


Weapons information_ 


G1 Build Sheet 
G1 Magazine Temp Log 
G1 Re-stow Sheet 
On Load & Flow Sheet 
Event Information 


G2 Build Sheet 
G2 Magazine Temp Log 
G2 Re-stow Sheet 
On Load & Flow Sheet 
Event Information 


G3 Build Sheet 
G3 Magazine Temp Log 
G3 Re-stow Sheet 
Magazine Arrangement 
Mission Load List 
Status Board 
Event Information 


On load & Flow Sheet 
Event Information 


On load & Flow Sheet 
Event Information 


Mission Load List 
Weapons inventory/info 
Event Information 


Bomb Farm Log 
On Load & Flow Sheet 
Weapons Location on Flight 
Deck/Hangar Deck 
Air Plan 

Airborne tanker status 
Aircraft Status (Deck) 
Aircraft Weight 
Alert Aircraft Status 
Event Information 
Event Information 
Recovery Video 
Weapons information 
ALRE Status 


Aircraft Bulletins 
ALRE Status/Information 
Aircraft Weight 
Event Information 
Head/Cross Wind, Wind 
Speed & Direction 
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WORK CENTER (USER) 



IDENTIFICATION 

LOCATION 

SYSTEM / 

LABEL 

(CV N68 class) 

Application 

(Data / Data Blocks) 

ICCS 3&4 

03-148-8-0 

ALRCS 

Aircraft Bulletins 

ICCS 3&4 

03-148-8-0 

ALRCS 

ALRE Status/Information 

ICCS 3&4 

03-138-2 

ISIS 

Aircraft Weight 

ICCS 3&4 

03-148-8-0 

ISIS 

Event Information 

Head/Cross Wind, Wind 

ICCS 3&4 

03-148-8-0 

MORIAH Wind 

Speed & Direction 

LENS RM 

03-123-10 

ECSS 

Basic Angle 

LENS RM 

010-160-1 

IFLOLS 

Air Officer Interlock Status 

LENS RM 

03-123-10 

IFLOLS 

Aircraft Hook to Eye 

LENS RM 

03-123-10 

IFLOLS 

Aircraft Type 

LENS RM 

03-123-10 

IFLOLS 

Barricade On Indicator 

LENS RM 

03-123-10 

IFLOLS 

Basic Angle 

LENS RM 

03-123-10 

IFLOLS 

Brightness Reset 

LENS RM 

03-123-10 

IFLOLS 

Datum/Wave Off/Cut Light 
Intensity 

LENS RM 

03-123-10 

IFLOLS 

Ship Navigation Information 

LENS RM 

03-123-10 

IFLOLS 

Source Light Intensity 

LENS RM 

03-123-10 

IFLOLS 

SPN-46 Heave 

LENS RM 

03-123-10 

IFLOLS 

SPN-46 Pitch 

LENS RM 

03-123-10 

IFLOLS 

SPN-46 Roll 

LENS RM 

03-123-10 

IFLOLS 

Stabilization Mode 

LENS RM 

03-123-10 

IFLOLS 

Wave Off 

LENS RM 

03-123-10 

IFLOLS 

Wave Off 

LENS RM 

03-123-10 

ILARTS 

Cut 

LENS RM 

03-123-10 

ILARTS 

Wave Off 

LENS RM 

03-123-10 

MOVLAS 

Cut 

LENS RM 

03-123-10 

MOVLAS 

Wave Off 

LENS RM 

03-123-10 

VISUAL 

Ship Navigation Information 

LENS RM 

03-123-10 

VISUAL 

Wind Speed & Direction 

LSO 

04-231-0 

VISUAL 

Air Officer Interlock Status 

LSO 

04-231-0 

VISUAL 

Aircraft Hook to Eye 

LSO 

04-231-0 

VISUAL 

Aircraft Type 

LSO 

04-231-0 

VISUAL 

Barricade On Indicator 

LSO 

04-231-0 

VISUAL 

Basic Angle 

LSO 

04-231-0 

VISUAL 

Cut light Indicator 

LSO 

04-231-0 

VISUAL 

Failure Mode 

LSO 

04-231-0 

VISUAL 

GO/NO GO 

LSO 

04-231-0 

VISUAL 

Hook to Ramp alarm 

LSO 

04-231-0 

VISUAL 

Hook to Ramp Warning 

LSO 

04-231-0 

VISUAL 

Low Cell Flash Rate 

LSO 

04-231-0 

VISUAL 

Low Cell Intensity 

LSO 

04-231-0 

VISUAL 

Power "on" 

LSO 

04-231-0 

VISUAL 

Ship List Information 

LSO 

04-231-0 

VISUAL 

Ship Trim Information 

LSO 

04-231-0 

VISUAL 

Source Light Intensity 

LSO 

04-231-0 

VISUAL 

Stabilization Mode 

LSO 

04-231-0 

VISUAL 

Targeted Wire # / HTD 
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WORK CENTER (USER) 


IDENTIFICATION 

LOCATION 
(CVN68 class) 

SYSTEM / 
Application 

LABEL 

(Data / Data Blocks) 

ISO 

04-231-0 

VISUAL 

Wave Off Indicator 

ISO 

04-231-0 

VISUAL 

Wave Off Location 

LSO 

04-231-0 

IQIQ 

ALRE Status 

ISO 

04-231-0 

VISUAL 

Event Information 

ISO 

04-231-0 

ISIS 

Event Information 

ISO 

04-231-0 

ISIS 

Pilot Oualifications/Grades 

ISO 

04-231-0 

VISUAL* 

Recovery Video 

LSO 

ISO 

04-231-0 

04-231-0 

1313 

VISUAL 

QDM Aa ln^r^ 

A/C DRIFT RATE 

ISO 

04-231-0 

VISUAL 

A/C IDENT 

ISO 

04-231-0 

VISUAL 

A/C RANGE 

ISO 

04-231-0 

VISUAL 

A/C SINK RATE 

ISO 

04-231-0 

VISUAL 

A/C SPEED 

ISO 

04-231-0 

VISUAL 

ACLS LOCK ON 

ISO 

04-231-0 

VISUAL 

ACLS MODE 

ISO 

04-231-0 

VISUAL 

Aircraft Bulletins 

ISO 

04-231-0 

VISUAL 

CLR/FOUL DECK 

ISO 

ISO 

04-231-0 

04-231-0 

VISUAL 

VISUAL 

Datum/Wave-Off/Cut Light 
Intensity 

Deck Status Light 

ISO 

04-231-0 

VISUAL 

Hook To Ramp Motion 

ISO 

04-231-0 

VISUAL 

Hook Touch Down (A/C) 

ISO 

04-231-0 

VISUAL 

Ramp motion 

ISO 

04-231-0 

VISUAL 

Wave Off 

ISO 

04-231-0 

VISUAL 

Wave Off 

ISO 

04-231-0 

VISUAL 

Weather Information 

ISO 

04-231-0 

VISUAL 

Wind (Head & Cross) Angle 

ISO 

04-231-0 

VISUAL 

Mr. Hands Information 

ISO Equipment Room 

03-233-2 

IFLOLS 

Cut 

ISO Equipment Room 

03-233-2 

IFLOLS 

Wave Off 

ISO Equipment Room 

03-233-2 

IFLOLS 

Wave Off 

ISO HUD 

04-231-0 

LSO HUD 

Wind Speed & Direction 

Main Comm 

03-108-0 

ISIS 

Air Plan 

Main Comm 

03-108-0 

ISIS 

Current Ship's Weather 

Main Comm 

03-108-0 

ISIS 

Event Information 

Main Comm 

03-108-0 

ISIS 

Event Information 

METOC 

06-160-3 

Moriah 

Ship Navigation Information 

METOC 

06-160-3 

MORIAH Wind 

Wind Speed & Direction 

Piiot House 

09-160-1 

ISIS 

Air Plan 

Piiot House 

09-160-1 

ISIS 

Airborne tanker status 

Piiot House 

09-160-1 

ISIS 

Aircraft Bulletins 

Piiot House 

09-160-1 

ISIS 

Aircraft Status (Deck) 

Piiot House 

09-160-1 

ISIS 

Aircraft Weight 

Piiot House 

09-160-1 

ISIS 

Alert Aircraft Status 

Piiot House 

09-160-1 

ISIS 

ALRE Status 

Piiot House 

09-160-1 

ISIS 

ASW Datum 
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WORK CENTER (USER) 



inFNTIFIHATinN 

LOCATION 

SYSTEM / 

LABEL 



(CVN68 class) 

Application 

(Data / Data Blocks) 

P 

lot House 

09-160-1 

ISIS 

Bingo Fuels 

P 

lot House 

09-160-1 

ISIS 

Current Ship's Position 

P 

lot House 

09-160-1 

ISIS 

Current Ship's Weather 

P 

lot House 

09-160-1 

ISIS 

Dally Call Signs 

P 

lot House 

09-160-1 

ISIS 

Divert Field Info 

P 

lot House 

09-160-1 

ISIS 

Event Information 

P 

lot House 

09-160-1 

ISIS 

Event Information 

P 

lot House 

09-160-1 

ISIS 

Helo Status 

P 

lot House 

09-160-1 

ISIS 

Pilot quallficatlons/grades 

P 

lot House 

09-160-1 

ISIS 

Plane Guard Ship 

P 

lot House 

09-160-1 

ISIS 

Recovery Video 

P 

lot House 

09-160-1 

ISIS 

SPN-46 Info 

P 

lot House 

09-160-1 

ISIS 

Tanker/Helo status (Deck) 

P 

lot House 

09-160-1 

MORIAH Wind 

Wind Speed & Direction 


PRI-FLY 

PRI-FLY 

PRI-FLY 

PRI-FLY 

PRI-FLY 

PRI-FLY 

PRI-FLY 

PRI-FLY 

PRI-FLY 

PRI-FLY 

PRI-FLY 

PRI-FLY 

PRI-FLY 

PRI-FLY 

010-160-1 

010-160-1 

010-160-1 

010-160-1 

010-160-1 

010-160-1 

010-160-1 

010-160-1 

010-160-1 

010-160-1 

010-160-1 

010-160-1 

010-160-1 

010-160-1 

AWIMS 

IFLOLS 

IFLOLS 

IFLOLS 

IFLOLS 

IFLOLS 

IFLOLS 

IFLOLS 

IFLOLS 

IFLOLS 

IFLOLS 

IFLOLS 

IFLOLS 

IFLOLS 

On Load & Flow Sheet 

Aircraft Hook to Eye 

Aircraft Type 

Barricade On Indicator 

Basic Angle 

Brightness Reset 

Cut light Indicator 
Datum/Wave-off/Cut Light 
Intensity 

Failure Mode 

GO/NO GO 

Hook to Ramp Meter - 
Dynamic 

Hook to Ramp Meter - static 
Hook to Ramp Warning 

Hook Touchdown meter - 
dynamic 

Hook Touchdown meter - 
static 

PRI-FLY 

010-160-1 

IFLOLS 


PRI-FLY 

010-160-1 

IFLOLS 

Low Cell Flash Rate 


PRI-FLY 

010-160-1 

IFLOLS 

Low Cell Intensity 


PRI-FLY 

010-160-1 

IFLOLS 

Power "on" 


PRI-FLY 

010-160-1 

IFLOLS 

PRI-FLY / Lens Room. Cmd. 


PRI-FLY 

010-160-1 

IFLOLS 

Ship List Information 


PRI-FLY 

010-160-1 

IFLOLS 

Ship Trim Information 


PRI-FLY 

010-160-1 

IFLOLS 

Source Light Intensity 


PRI-FLY 

010-160-1 

IFLOLS 

Stabilization Mode 


PRI-FLY 

010-160-1 

IFLOLS 

Targeted Wire # / HTD 


PRI-FLY 

010-160-1 

IFLOLS 

Wave Off Indicator 


PRI-FLY 

010-160-1 

IFLOLS 

Wave Off 


PRI-FLY 

010-160-1 

IFLOLS 

Wave Off Location 


PRI-FLY 

010-160-1 

ISIS 

Air Plan 


PRI-FLY 

010-160-1 

ISIS 

Airborne tanker status 
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WORK CENTER (USER) 


IDENTIFICATION 

LOCATION 

SYSTEM / 

LABEL 

(CVN68 class) 

Application 

(Data / Data Biocks) 

PRI-FLY 

010-160-1 

ISIS 

Aircraft Buiietins 

PRI-FLY 

010-160-1 

ISIS 

Aircraft Status (Deck) 

PRI-FLY 

010-160-1 

ISIS 

Aircraft Weight 

PRI-FLY 

010-160-1 

ISIS 

Aiert Aircraft Status 

PRI-FLY 

010-160-1 

ISIS 

ALRE Status 

PRI-FLY 

010-160-1 

ISIS 

ASW Datum 

PRI-FLY 

010-160-1 

ISIS 

Bingo Fueis 

PRI-FLY 

010-1 60-1 

ISIS 

Current Ship's Position 

PRI-FLY 

010-160-1 

ISIS 

Current Ship's Weather 

PRI-FLY 

010-160-1 

ISIS 

Daiiy Caii Signs 

PRI-FLY 

010-160-1 

ISIS 

Divert Fieid Info 

PRI-FLY 

010-160-1 

ISIS 

Event Information 

PRI-FLY 

010-160-1 

ISIS 

Event Information 

PRI-FLY 

010-160-1 

ISIS 

Heio Status 

PRI-FLY 

010-160-1 

ISIS 

Piiot quaiifications/grades 

PRI-FLY 

010-160-1 

ISIS 

Piane Guard Ship 

PRI-FLY 

010-160-1 

ISIS 

Recovery Video 

PRI-FLY 

010-160-1 

ISIS 

SPN-46 info 

PRI-FLY 

010-160-1 

ISIS 

Tanker/Heio status (Deck) 

PRI-FLY 

010-160-1 

MORIAH Wind 

Wind Speed 

Ready Room/MC 

03-220/50 -0 

AWIMS 

Mission Load List 

Ready Room/MC 

03-220/50 -0 

AWIMS 

Weapons Information 

Ready Room/MC 

03-220/50 -0 

ISIS 

Air Pian 

Ready Room/MC 

03-220/50 -0 

ISIS 

Airborne Tanker Status 

Ready Room/MC 

03-220/50 -0 

ISIS 

Aircraft Status (Deck) 

Ready Room/MC 

03-220/50 -0 

ISIS 

Aircraft Weight 

Ready Room/MC 

03-220/50 -0 

ISIS 

Aiert Aircraft Status 

Ready Room/MC 

03-220/50 -0 

ISIS 

ASW Datum 

Ready Room/MC 

03-220/50 -0 

ISIS 

Bingo Fueis 

Ready Room/MC 

03-220/50 -0 

ISIS 

Charts / Maps 

Ready Room/MC 

03-220/50 -0 

ISIS 

Current Ship's position 

Ready Room/MC 

03-220/50 -0 

ISIS 

Current Ship's Weather 

Ready Room/MC 

03-220/50 -0 

ISIS 

Divert Aircraft Status 

Ready Room/MC 

03-220/50 -0 

ISIS 

Divert Fieid Info 

Ready Room/MC 

03-220/50 -0 

ISIS 

Event Information 

Ready Room/MC 

03-220/50 -0 

ISIS 

Event Information 

Ready Room/MC 

03-220/50 -0 

ISIS 

Heio Status 

Ready Room/MC 

03-220/50 -0 

ISIS 

Piiot Quaiifications/Grades 

Ready Room/MC 

03-220/50 -0 

ISIS 

Piane Guard Ship 

Ready Room/MC 

03-220/50 -0 

ISIS 

Recovery Video 

Ready Room/MC 

03-220/50 -0 

ISIS 

Ship's PIM 

Ready Room/MC 

03-220/50 -0 

ISIS 

Tanker/Heio status (Deck) 

Ready Room/MC 

03-220/50 -0 

ISIS 

Wind Over Deck 

SEC CONN Station 

4-124-1-C 

MORIAH Wind 

Wind Speed & Direction 

SPN46 

07-175-3 

SPN-46 

Wind Speed & Direction 
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WORK CENTER (USER) 



IDENTIFICATION 

LOCATION 
(CVN68 class) 

SYSTEM / 
Application 

LABEL 

(Data / Data Blocks) 

SPN-46 

07-175-3 

SPN-46 

Basic Angle (IFLOLS) 

SPN-46 

07-175-3 

SPN-46 

Ship Navigation Information 

SPN-46 

07-175-3 

SPN-46 

VISUAL Tracking Data 

SPN-46 

07-175-3 

SPN-46 

Wave -off 

Strike Ops 

03-138-1 

AWIMS 

Mission Load List 

Strike Ops 

03-138-1 

ISIS 

Air Plan 

Strike Ops 

03-138-1 

ISIS 

Aircraft Status (Deck) 

Strike Ops 

03-138-1 

ISIS 

ALRE Status 

Strike Ops 

03-138-1 

ISIS 

Divert Field Info 

Strike Ops 

03-138-1 

ISIS 

Event Information 

Strike Ops 

03-138-1 

ISIS 

Ship's PIM 

Strike Ops 

03-138-1 

ISIS 

Weapons information 

Tacticai Operations Piot 

09-162-1 

MORIAH Wind 

Wind Speed & Direction 

TFCC 

03-150-0 

MORIAH Wind 

Wind Speed & Direction 

V-2 Division Office 

03-79-0 

ADMACS 

Aircraft Bulletins 

V-2 Division Office 

03-79-0 

ALRCS 

ALRE Status/Information 

V-2 Division Office 

03-79-0 

ISIS 

Event Information 

V-2 Maintenance Office 

03-79-0 

ADMACS 

Aircraft Bulletins 

V-2 Maintenance Office 

03-79-0 

ALRCS 

ALRE Status/Information 

V-2 Maintenance Office 

03-79-0 

ISIS 

Event Information 

V-4 Division Office 

02-79-P 

ALRCS 

ALRE Status/Information 

V-4 Division Office 

02-79-P 

ISIS 

Event Information 

WPNS DEPT CC 

02-165-2-Q 

AWIMS 

On Load & Flow Sheet 

WPNS DEPT CC 

02-165-2-Q 

ISIS 

Event Information 
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APPENDIX B: AIRCRAFT HANDLER'S QUESTIONNAIRE 


1. Describe the most complex task you perform in the normal course of the day’s 
events. 

2. Describe the most time consuming aspect of your job. 

3. If you could automate specific portions of your job, what would you automate and 
to what degree. (List as many as you wish - prioritize them with 1 being the 
highest priority). 

4. Are there aspects of your job that you feel should never be abandoned by “human 
intelligence”, i.e. which should never be automated? What are they and why is it 
they should be left as is? 

5. Are there aspects of your job that you cannot spend adequate time on because of 
either time constraints or other extraneous constraints that keep you from them? 

6. Would a decision support system that is able to display a “Spot Plan” given the air 
plan requirements, the aircraft availability, weapons load, etc. be a welcomed 
“tool”, or would you view this as a threat to your job? If it were perceived as a 
threat, what would make it less threatening in your eyes? 

7. In the planning stages of preparing for a specific launch (first go, second go, third 
go), are there redundant tasks that could be automated? 

8. What specific inputs should be taken into consideration? 

9. For display purposes, is a color display preferred over monochrome? 

10. Who else would you want to have input to this effort to digitize the Ouija board? 

11. To what extent would you want their input? 

12. Are their specific questions or inputs that we should ask of them? 

13. Are their other inputs that you would like to provide us with? 

14. Are their specific Handlers (current or otherwise) that you would recommend we 
survey (Please provide information to help us locate them, e.g. Command Name or 
e-mail address)? 
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15. Rate the functionality of the following hardware in support of handling aircraft: 


Rate 1 to 5 

(5 is Excellent, 

1 is Very Poor) 

Maintenance 

Control 

Ready 

Room 

Bridge 

Air Boss 

Flight Deck 
Control 

Flight 

Deck 

Hangar 

Deck 

Hand held 
devices (PDAs) 








Wearable 

computers 








Heads-up 
displays (on 

Yellow Shirts, 

Blue Shirts, etc.) 








Touch screen 
displays 








Pen tablets 








Hands -free 
computing 








Virtual Displays 
(3D graphic 
representation of 
objects and 
environment) 
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APPENDIX C: RESULTS OF QUESTIONNAIRE 


From CVN-73 Handler 


1. Display positions of JBD, bomb/missile elevators, whip 
antennae, and elevators. 

2. Generate statistics per pilot (an aircraft's pilot can 
be retrieved from ISIS) like flying time, recoveries by 
arresting wire number, aircraft maintenance. 

3. Generate statistics per shipboard personnel (time per 
wash down, fueling/de-fueling efficiencies). 

4. Generate statistics per aircraft like time to launch, 
counts by arresting wire number, wash-downs, down rate, de¬ 
fuels . 

5. Generate statistics per ship like sortie rate. 

6. Optimize aircraft re-spots. 

7. Perform support functions (like Maximum Spotting Density 
for the Spotting Room). 

8. Mobilize the Ouija board so that anyone on the ship's 
LAN can visualize info and/or the Handler can generate the next 
day's spotting configurations from the head, his stateroom, or 
the beach. 

9. Zoom in on digital sections of the flight deck. The 
colored aircraft templates currently used would be replaced by 
vector (CAD like) drawings that allow highly accurate 
investigations of spotting configurations. 

10. Select a camera and display what it is seeing. 

11. Zoom in on a subsection. 
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12. Digital enhancement of the video (sharpening, contrast 
enhancement) under user control. 

13. Touch a camera icon then an aircraft to automatically 
bring up video and zoom (you won't have to specify a camera and 
touch out the zoom region). 

14. Store all aircraft movements for an entire cruise. 
These could be searched (for F18 bow re-spots at night), 
replayed with VCR-like controls (fast forward, reverse, pause), 
and saved. 

15. Panoramic view (digitally create an image mosaic of the 
entire flight or hangar deck) . This may have some problems 
because not all cameras will have the same viewing position. 
For example, the Aft Radar Mast Camera will be around 150' aft 
of the island cameras and at lower elevation. The mosaic may be 
strange. We could patch together a single image on the next 
cruise to give Handlers an idea. 

16. Emergency video recording. In case of an emergency (or 
for training), the computer could start archiving a camera's 
imagery (or subsection). I would guess you could only save 5 to 
10 minutes before hard drives filled up. Alternatively, you 
could have a standby recorder co-located with the workstation 
and clicking an option would save imagery to a SVHS tape with 
hours of storage potential. 


17 . 

Count 

the 

elevator runs 

(from 

Mr. 

Husni' s 

kickoff 

meeting 

notes) . 







18 . 

Count 

the 

aircraft moves 

(from 

Mr. 

Husni' s 

kickoff 

meeting 

notes) . 
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19. Render the decks with holographs (the Navy has been 
researching washtub-like rendering displays for years) so that 
everything appears in 3D. 

20. Retrieve video snippets from a ship's cruise (e.g. 
"Show me all of 105's nighttime recoveries.") . The degree of 
automation would be contingent on what equipment you buy and how 
you hook it up. For example, EATS will automatically be able to 
print out a list for the above without any additional equipment. 
You could then walk to the PLAT camera room and try to retrieve 
the video from their circular storage system (a drawer of tapes 
with the last - or most recent - tape put in being the last to 
be reused). This would be pretty onerous because of the manual 
review of many tapes but the timestamps are on the tapes. 
Alternatively, EATS video could be streamed to a bank of tape 
decks. This gives EATS more control of the imagery and 
potentially allows EATS to automatically generate one tape from 
its list of "interesting events" and extraction of video data 
from banks of decks through digital control. 

21. Digital storage of "interesting events." A user (from 
Pri-fly or a training air space, etc...) could say "Log all 
recoveries for 310." EATS would then temporarily store each 
recovery and upon finding out that the recovered aircraft (from 
ISIS) was 310, would stream the data onto the network to the 
designated airspace. If it weren't 310, EATS would write over 
the data. I don't know how maintenance works but I would think 
this may be handy where something on an aircraft was suspicious 
and they might want to review it in slow-motion when they had 
time (like a faulty aileron). 

22. EATS could allow the zoom-in, observation, and tracking 
of personnel. 
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23. EATS may allow some gross form of FOD detection. 


24. EATS may allow some gross form of ordnance inspection. 

25. Fouled deck detection (in addition to numerous others). 


From Commander Yoast, Aircraft Handler for CVN-73 

and Aviation Bosun Mate Alan Procter 

Most tense movement is when a Deck Edge Elevator is down. 
It is very difficult because it involves coordination amongst so 
many spaces. Tension is up. 2 minutes after it is down, the 
operator will get a call from the bridge about when it can come 
up again. CCTV hangar bay cameras allow him to recall the 
elevator quickly. Two cameras have pan/tilt/zoom. 

Joe Breslen Memorial Camera monitors the bow catapults so 
that when the ILARTS camera is switched to recoveries and the 
ship is still launching aircraft, something is recording that 
area. It is a low light level camera with a fixed aperture. 

Another 360-degree camera (actually much less, probably 
180) is used for spotting board operators (an Elevator Operator 
(EO) ) . AH can bring a guy down from the 08 level on the sound 
powered phones or from within the ILARTS booth down below and 
they just use the CCTV to spot ships. The camera has pan, tilt 
and zoom. This low light camera (not "Dage", but off the shelf) 
must function with lots of glare in daytime but also work well 
at night. This might be fixed with a new monitor. 
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APPENDIX D: INPUT/OUTPUT SURVEY 















































Squadron Operations 


Squadron Plan of the Day (POD) 
Pilot Qualifications 
Squadron Duty Roster 
Pilot Medical Status 
Pilot Landing Grades 
Squadron Training Plan 
Squadron Flight Schedule 

CAG Operations 

Aircraft Performance Parameters 

Air Wing Tactics 

Rules of Engagement 

Threat Intelligence 

Target / Op Area Information 
(Maps, coordinates, etc) 

Target Photos 

Strike Plan 

Squadron Maintenance 
(Repeated for each squadron) 

Squadron Maintenance Plan 
Squadron Flight Hour Records 
Aircraft Maintenance Records 


1 


ADMACS 

ISIS 

Grumman 

EATS 



ADMACS 

ISIS 

Grvimman 

EATS 



ADMACS 

ISIS 

Grumman 

EATS 
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APPENDIX E: RESPONSE TO INPUT/OUTPUT SURVEY 


Response from CW02 David Young, youngd@kitty-Hawk.navy.mil; 
COMM: 243-4295, X-6540 Fuels Maintenance Officer CV63. 


V-4 / Fuels 
Division 

Others 

11 

Total Fuel 

System Status 

8 O'clock reports 

12 

A/C Fueling 
Status 

Checker Cards And Log Sheets Are Used To 
Track A/C Start Loads and Top Off Loads. 
We Use This Information To Track Each 

Individual Aircraft Fuel Issue. 

13 

Fuel Crew 

Management 

COMNAVAIRPAC/COMNAVAIRLANT Instruction 

3500.71a 

14 

Fuel Station 

Status 

F/D Repair Personnel Physically Check 
During R-42/44 PMS Check. Use 8 O'clock 
Reports And Division Fuel Station Status 
Report To Track Status. 

15 

Fuel Plan 

Use Air Plan For Fuel Load Of Aircraft. 

Use AFOSS To Plan For Fuel UNREPS. 


Response from LCDR Michael Shults [mshult@lincoln.navy.mil]. 
Ordnance Handling Officer (OHO) for CVN-72 



Weapons 

Department 

Others 

34 

Replenishment 

Requirements 

ROLMS/E-mail inputs to LOG REC 

35 

Replenishment 

Planning 

ROLMS/E-mail 

36 

Magazine 

Inventory 

ROLMS 

37 

Movement Plan 

NONE- coordinated by Ordnance control. 
Ordnance Handling Officer (OHO) 

38 

Build Plan 

None- coordinated by Ordnance control, 

OHO 

39 

Break Out Plan 

None- coordinated by Ordnance control, 

OHO 
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Load Plan 


In puts provided to Strike Ops by phone 
or in person/E-mail. 
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APPENDIX F: ADMACS DEPLOYMENT PLANTS 


AC TI\ IT\ 

PROCUREMENT 

INSTALLATION 

CV 63 USS Kitty Hawk 

FY02 

FY03 

CVN 65 USS Enterprise 

FYOl 

FY02 

CV 67 USS John F. Kennedy 

FY()2 

FY03 

CVN 68 USS Nimitz 

FYd8 

FYOO 

CVN 6d USS Dwight D. Eisenliower 

FYilo 

FY02 

CVN 70 USS Carl Vinson 

FYOl 

FY02 

CVN 71 USS Theodore Roosevelt 

FYOl 

FY02 

CVN 72 USS Abraham Lincoln 

FYoo 

FY(H 

CVN 73 USS George Washington 

FYOO 

FYOl 

CVN 74 USS John C. Stennis 

FYOO 

FYOl 

eV'N 75 USS Hany S. Truman 

FYOO 

FYOl 

CVN 76 USS Ronald Reagan 

FYOO 

FYOl 


55 N78-NTSP-A-50-0009/D, Navy Training System Plan For The Aviation Data Management 
And Control System, March 2001 
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